Compilation errors

[Svenstaro]

You are doing it like on Windows. On Linux you won't have to set up all that stuff manually. I'm going to assume that you have installed the SFML package from community.

Do this in a terminal:

Code: [Select]

wget http://sfml-dev.org/tutorials/1.6/sources/audio-sound.cpp
g++ -lsfml-audio -lsfml-system audio-sound.cpp

That's all you have to do to generate a working sfml binary! Run the resulting a.out file (it will require a sound.wav to actually work).

[kiaran]

Svenstaro- Thanks for you help. This linux stuff is daunting.

I eventually managed to get that compile error to disappear. Its been a really frustrating experience, because I still have no idea what the exact problem was. But through much trial and error I determined that the NAME of the Status enum defined in Sound.hpp was simply not going to work.

In the end, all I did was rename the enum variable from "Status" to "Stat:. I know it sounds ridiculous, but that let everything compile and run.

I HAVE NO CLUE WHY. I hate 'mystery' crap like this so any insight would be appreciated. Heck, I'd even take a wild theory at this point because I have no idea why this name change would have this affect.

[Laurent]

Hey, thanks for your help
Maybe now I'll be able to figure out what's wrong.

[Laurent]

By the way, do you include any other header before <SFML/Audio.hpp>? Does this error happen when you compile this simple example?

Code: [Select]

#include <SFML/Audio.hpp>

int main()
{
    return 0;
}

[kiaran]

I'm not including anything before Audio.hpp.

I'll try to compile that minimal test. Right now I'm under the gun to get this linux build finished.

[Svenstaro]

kiaran, did my minimal example work out of the box for you?

[kiaran]

Svenstaro - I manually installed the SFML package and pointed my binary to local versions of the libraries. I'm hoping this makes it easier to distribute my application this way since it's more self-contained it should be less error prone.

I looked into installing the public package from the gcc tutorial but it doens't make any sense to me. From the tutorial:

Once you have downloaded and extracted the files to your hard drive, you must install the SFML headers and library files to the appropriate location. To do so, you just have to go to the SFML-x.y directory and type "sudo make install".

Where is the SFML-x.y directory in the download? I don't see it.

Edit: So no, I wasn't able to get your minimal example working because I haven't installed SFML in a system-wide way.

[Svenstaro]

Why do not install SFML system wide? Any users wanting to play your game will only have to get SFML from your their repos and be able to play it. In Linux land you won't have to provide all deps yourself, that's the nice thing.

EDIT: If you really want SFML to be statically linked, why not do that?

[kiaran]

Yeah, I think I will take a stab at statically linking it.  I know not all open source software licenses (SDL) let you do that. I was being cautious by dynamically linking.

The reason I don't want to rely on system-level libraries is because I really don't want the headache of supporting less technically inclined users with questions about missing dependencies. When you buy a game it should 'just work'.

I was looking at how World of Goo does it. They basically run the game from a shell script which points the binary to a local directory to search for needed libraries before looking to the global usr/lib folder.
export LD_LIBRARY_PATH="./libs":"$LD_LIBRARY_PATH"

I'm not crazy about using a shell script to launch the game, but I can't statically link everything my game uses... so lesser of two evils I guess.

[Svenstaro]

Indeed, I usually do it with the LD_LIBRARY_PATH thing but only if the dependencies are outdated on the usual distributions. The problem is that it blows up your game package's size almost to Windows levels and you will have to provide two architectures too.

I usually try to keep the headache small for myself and let packagers of other distributions package my games. Why not safe yourself the trouble as well?

What license are you using that you would get trouble with statically linking, by the way? If you choose GPL for your application, you will get no problems, no matter what license they are.

[kiaran]

Well, this a commercial product so it's not going to be available in any repo anywhere or anything.

I was planning on just having a download .tar with a shell script that checks for the 32/64bit and points to the correct binary/libraries.

Regarding statically linking: I'm using SDL and I think I read somewhere that you can only statically link it into an open source program, which mine is definitely not.

I'm only using SFML for it's nice interface with OpenAL. On a completely unrelated note, I tried porting my project to SFML for window management and input a while ago but ran into too many issues so I just had to abandon. But I'm happy with the mix of components I'm using now. I wrote an article about it if you care to see exactly what I'm doing:

http://www.bigfatalien.com/?p=110

[Svenstaro]

You can still get around it and make everyone happy (and yourself too!) by opensourcing the engine and making the game commercial. That should work nicely to your advantage as well.

[kiaran]

Open sourcing the engine is something I'm looking into. B

But I'm using commercial 3d software for level design which I don't think would be very useful to many people. Still, if someone really wanted to they could build their own content pipeline without my toolset...

[Svenstaro]

If you can use a common output format for the levels (which is a good idea in any case) you can also use other software for that.