Ok...I've never actually did any linux programming before, but I made my project multiplatform as I could. Everything compiles just fine, and I can even run the resulting executeable while in Code Blocks....but when I try to run the program from within KDE it trys to open a window and closes down with no error message or anything ! I use GFX_AUTODETECT_WINDOWED...I read in the manual that the accelerated drivers require root access...how do I do that so my end users can have accelerated graphics? I don't know if that is the problem, but seems likely to me...any suggestions or comments on this would be a great help...::)

Thanks to all,
Donald

Run it from a terminal and it will probably say "Shutting down Allegro due to signal number 11". Find out what file you aren't checking fails to load, and fix the problem

It tries to open a file, but this fails. Make sure the program looks for the file in a sensible location (such as the location of the executable, for instance), not just the current directory.

You don't. The adminstrator has to install the program in such a way that it runs with root privileges ("suid root").

No.

EDIT (from below)

Actually, signal 11 means a segmentation fault.

See that is what I thought might also be the problem (trying to load an image, but fails)...the program looks for the GFX/ folder in the current directory to get it's graphics...I even changed the code so it would just load from the current directory...same thing!

Edit:
Found how to run the console command...been a while since I used linux...::)
Yeah...it seg faults with 11...so it's not looking for the right file, but why does it work from CodeBlocks?

Edit #2:
Ok...this is even weirder...it runs from CodeBlocks and the console using ./War but when I click the icon in KDE...it doesn't actual continue to load!? WTF!

Edit #3:
I attached the zip...it contains the executable and the graphics...

#2
in linux you have to set the current path by yourself - this is code i'm using:

#ifndef _WIN32
char path [128];
get_executable_name(path,128);
replace_filename(path,path,"",128);
chdir(path);
#endif

This has nothing to do with Linux versus Windows, and it's wrong

The path is the same as the path you were at when you ran the program. If you ran it from the same directory ("./program"), the CWD will be that directory.

Don: Use a log file to find out which bitmap fails to load.

[append]
I like this idea better, actually:

freopen("output.txt", "w", stdout);
freopen("errors.txt", "w", stderr);

Put that in main, run the program, and check those files.

Both wrong, in linux the working directory is (AFAIK) the home directory of the current user.
The code written by Frank Drebin should work perfectly.

Wrong again.
The current working directory (CWD) defaults to the CWD of the parent process. If launching from a a file manager, this could very well be the user's home directory; if you run it from a terminal, it's normally fairly obvious what the CWD is.

Yes. Except that you normally need the exact same code in Windows too.

Are you serious?

Evert:
That totally makes sense! But how would you know at runtime what the CMD would be? I want to keep this as portable as possible, but I am just learning how the linux system is setup and what is stored where...also...at least on my machine, you are correct Evert. The CMD is set to the users home. I copyed the files there and it ran just fine!

Hmmm. The Mac version of Allegro sets the cwd to be the resources folder of your application bundle (or an Allegro-specific subdirectory of it if that exists), would it make sense to have the other platforms automatically set the cwd to wherever the executable is so that behaviour is "uniform" across platforms in the sense that it sets the cwd to be where your data files probably are?

getcwd

Probably not.
For one thing, this breaks current programs (so it breaks the API), for another, at least on UNIX system, exectables are normally not kept in the same location as the game's datafiles, so it wouldn't be the proper analogue. It will also make it harder to write programs that take a filename from the commandline.

The MacOS X port is special in this, but I think that makes sense, since the concept of application bundles is also MacOS X specific (and something I actually quite like).

EDIT

Then you should definately include that code; as I said, it's generally also nescessary in Windows.

Since we're on the subject of application bundles, how come you cant load the special "#" datafile when your executable is in an application bundle?

My guess is that it's looking for the game executable in the resource directory of the application bundle and fails to find it (thus failing to load the embedded datafile), but that's just a random guess (yes, I'm saying that's a bug).
On the other hand, if your program is in a bundle, why do you need to append the datafile to the executable in the first place?

EDIT: For got to reply to this before

In that the administrator has to install the program to use root privileges rather than the user just telling it to? Of course I am, it wouldn't make sense otherwise.

Because you're porting your game over from windows and would prefer to maintain the same build system. That and maybe you want to make your game data just a bit harder for someone to reverse engineer.

Can't do that anyway; linking options are already different and Windows doesn't know about application bundles in the first place.

It was easy to add new options to my build system for OSX, but to change the location of the datafile requires me to write new code to handle that and make other weird changes to my build system that don't fit well with the other OS's build system stuff.

But I've already done it all anyway. I just think it would be cool if "#" worked. After all, the docs do say it does.

As I said, it's a bug.