external libraries and distribution

Is there a checklist of things I must bundle with a program which uses external libraries to ensure that it will work on other computers when downloaded from my site?

I tried running a simple SDL app I made on another computer, but all I got was a dos window flash up and then disappear immediately. I included all the .dll files in the zip, but I can't think what else I would need to include.

here's the zip for anyone interested.

link

Any help is, as usual, greatly appreciated,

Regards,

Stonehambey

run it from the console.

Are you catching errors/exceptions and logging them?

Quote:

---

Originally Posted by robwhit

run it from the console.

---

I'm not sure I follow, exactly :)

Quote:

---

Are you catching errors/exceptions and logging them?

---

If something doesn't load or fails to initialize it returns a number other than 0, much like the lazy foo way. However I quickly learnt that always returning 1 didn't really help me locate errors, so the program returns different numbers depending on which part has failed. When testing it in the IDE (code blocks, in my case) it just tells me which number was returned when I run the program, making the problem easy to find. I'm unaware how to find out this information when not running it within the IDE. Forgive my ignorance if it should be obvious to me :)

Create a logger object that logs information to a file.

Quote:

---

Originally Posted by Stonehambey

I'm not sure I follow, exactly :)

---

Well, he's saying run the program using command prompt (cmd.exe). Just go to Run -> cmd.exe. Then just go to the path where your program is located then type in the program name and see what it spits out.

Short summary of (DOS/Windows) console commands:

• cd: change directory. Change to the directory your executable is located in. Use \ to separate folders. For example: cd "\Documents and Settings\User"
• program: type the name of a program to run it, with or without the .exe extension.
• dir: list the files in the current directory. You can use something like dir *.exe to see what exe files are present.
• exit: what do you think? ;)

That's what I thought he might mean, what's the difference between running a program that way and just double clicking on the .exe?

Anyway, I still get the same problem. :(

As a point of interest. I can run the SDL programs from your site, dwks. However when I try to run them from another computer, I get exactly the same problem (window flashes open then closes immediately), despite all the correct .dll files being on the computer.

Might this suggest that the problem is not specifically with my programs, but something more general? It seems that my computer, on which I've developed an SDL app, likes SDL apps just fine. But other computers don't seem to like them so much :(

Quote:

---

Originally Posted by Stonehambey

That's what I thought he might mean, what's the difference between running a program that way and just double clicking on the .exe?

Anyway, I still get the same problem. :(

As a point of interest. I can run the SDL programs from your site, dwks. However when I try to run them from another computer, I get exactly the same problem (window flashes open then closes immediately), despite all the correct .dll files being on the computer.

Might this suggest that the problem is not specifically with my programs, but something more general? It seems that my computer, on which I've developed an SDL app, likes SDL apps just fine. But other computers don't seem to like them so much :(

---

That's exactly why we were suggesting that you run programs from the command prompt. When you do so, the window doesn't flash and disappear before you can read it; it stays open. That way, you can look at any error messages that might have been printed.

By the way, anything my SDL applications print to the console window they also generally write to a log file, sailseas.log for Sail the Seas, xuni.log or test.log for xuni, and so on. For exactly the reason you've encountered.

<shameless-plug>If you like my projects, you should look at the latest version of xuni, from here: xuni.sourceforge.net
Plus you can use codeform to highlight large portions of code that you post on CBoard . . . </shameless-plug>

As for SDL apps . . . well, you have to have the right DLLs. However, when you run a program that requires a DLL, and that DLL is not present, you'll get an error message in a dialog box saying which DLL is missing (I think -- it's been a while). So that's probably not the case.

Is the system that your program does not work on a Vista one, by any chance? There might be some permissions issues with DLLs under Vista. I really have no idea.

I thought DLLs could be in the current directory, but maybe they have to be in the system directory on Vista or under all Windows systems. Do you have SDL.DLL in, say, \windows\system32 or something?

Or is this a versioning problem? What version of SDL was the program compiled with, and what is it running against?

I tried it on two computers, both XP. One had the .dll files in the windows/system32 folder, the other just in the same directory as the app. At first some of the dll's were missing, and it gave an error message like you said. After all the dll's were added, it stopped moaning.

The console window doesn't print anything.

I guess I'm not really helping myself if I'm not logging my errors properly. I thought maybe someone might have had a similar distribution problem and had a suggestion :P

EDIT:

Quote:

---

Or is this a versioning problem? What version of SDL was the program compiled with, and what is it running against?

---

It's the latest SDL, compiled on code::blocks on Windows Vista :)

Quote:

---

Originally Posted by Stonehambey

It's the latest SDL, compiled on code::blocks on Windows Vista :)

---

Is the one you compiled with the same one on the target machine?

Quote:

---

Originally Posted by medievalelks

Is the one you compiled with the same one on the target machine?

---

The versions of SDL are the same yes, in fact the .dll files were copied straight from my machine

Quote:

---

Originally Posted by Stonehambey

The versions of SDL are the same yes, in fact the .dll files were copied straight from my machine

---

The only thing I can think of is that perhaps another, older version is in the path somewhere.

Are there any other DLLs that your application depends on?

Not that I can think of. :)

Here's the source of the program,

http://stonehambey.com/source/KeyEvent.zip

It's mostly just a lazy foo tutorial, but with a few small changes, so I honestly can't see where the problem would be. Perhaps something to do with the way the IDE builds the project?

I see you're using SDL_ttf -- you'll need SDL_ttf.dll as well. :)

[edit] And SDL_image.dll too. [/edit]

[edit=2] And if you're loading JPG images, you'll need other DLLs as well. Here's what I distribute with most of my projects.

Code:

---

jpeg.dll
libpng12.dll
libtiff.dll
SDL.dll
SDL_image.dll
SDL_ttf.dll
zlib1.dll

---

If you're loading PNGs, you'll need libpng12.dll and zlib1.dll. I think you only need jpeg.dll for JPEGs. If you want to be safe, distribute all three. :) They're not really that large.

If you don't have any of these DLLs, you can download them along with one of my programs, xuni. http://downloads.sourceforge.net/xun...4&big_mirror=0
The DLLs I mentioned, plus libexpat.dll (for expat, an XML parsing library), are all there.

Or you could do some work and download the DLLs from libsdl.org yourself. I think mine are reasonably up-to-date, though. [/edit]

[edit=3] BTW, your program compiles and runs just fine on my Linux system like so:

Code:

---

$ g++ -I /usr/include/SDL SDLfunctions.cpp KeyEvent.cpp -o KeyEvent -lSDL -lSDL_image -lSDL_ttf
KeyEvent.cpp:30: warning: missing initializer for member ‘SDL_Color::unused’
KeyEvent.cpp:100: warning: unused parameter ‘argc’
KeyEvent.cpp:100: warning: unused parameter ‘args’
$ ./KeyEvent
$

---

What do you know -- it's cross-platform already! [/edit]

I included the files you suggested and tried it on another machine and...it worked!

I still wanna try it on a few other machines in case it was a fluke, but it's definitely a step in the right direction. Thanks :)