Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Linux programming...

Credits go to Evert for helping out!
This thread is locked; no one can reply to it. rss feed Print
Linux programming...
Don Freeman
Member #5,110
October 2004
avatar

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 :o! 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

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

CGamesPlay
Member #2,559
July 2002
avatar

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 ;)

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Evert
Member #794
November 2000
avatar

Quote:

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 :o!

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.

Quote:

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?

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

Quote:

I don't know if that is the problem

No.

EDIT (from below)

Quote:

it seg faults with 11

Actually, signal 11 means a segmentation fault.

Don Freeman
Member #5,110
October 2004
avatar

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...

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Frank Drebin
Member #2,987
December 2002
avatar

#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

CGamesPlay
Member #2,559
July 2002
avatar

Quote:

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

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.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

psycho
Member #5,042
September 2004

Quote:

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.

Quote:

in linux you have to set the current path by yourself

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.

Evert
Member #794
November 2000
avatar

Quote:

Both wrong, in linux the working directory is (AFAIK) the home directory of the current user.

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.

Quote:

The code written by Frank Drebin should work perfectly.

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

Michael Faerber
Member #4,800
July 2004
avatar

Quote:

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

Are you serious? :o:o

--
"The basic of informatics is Microsoft Office." - An informatics teacher in our school
"Do you know Linux?" "Linux? Isn't that something for visually impaired people?"

Don Freeman
Member #5,110
October 2004
avatar

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!

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Thomas Harte
Member #33
April 2000
avatar

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?

Evert
Member #794
November 2000
avatar

Quote:

But how would you know at runtime what the CMD would be?

getcwd

Quote:

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?

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

Quote:

I want to keep this as portable as possible

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

ImLeftFooted
Member #3,935
October 2003
avatar

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?

Evert
Member #794
November 2000
avatar

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

Quote:

Are you serious?

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.

ImLeftFooted
Member #3,935
October 2003
avatar

Quote:

why do you need to append the datafile to the executable in the first place?

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.

Evert
Member #794
November 2000
avatar

Quote:

Because you're porting your game over from windows and would prefer to maintain the same build system.

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

ImLeftFooted
Member #3,935
October 2003
avatar

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.

Evert
Member #794
November 2000
avatar

Quote:

I just think it would be cool if "#" worked. After all, the docs do say it does.

As I said, it's a bug.

Go to: