I am putting together a simple game on my main Debian Testing machine. I'm fairly inexperienced with software development in general, software development on Linux-based systems in particular, and game programming on Linux-based systems in even more particular. That said, I find that the project works fine on my main system, and if I build it on another Debian system it will work fine, but when I moved the already-built binary to a second machine that runs Debian Stable, I get an error:

Quote: ./oracleseye: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

From what I've been able to find on my limited searching online, it seems to be a problem with the changeover from GCC 3.3 to 3.4. Apparently they are not binary compatible? That's fine, but I would like to be able to make sure my game works without needing someone to compile it if they don't want to do so. It would especially be nice to send someone a 1.5MB file with just the binaries needed to playtest the game rather than expect them to download an 8MB file and then build the project each time. I can still play older games like Quake 3 Arena on my system, and I believe that had to have been compiled back when the Linux kernel was 2.2. Obviously it is possible to make binaries that run in multiple configurations, but I am not sure what to do. Would I need to compile libstdc++ statically? Will I just need to provide multiple binaries and go through the headaches of explaining to people that their system upgrades require a different file in order to play? Am I not understanding how fundamental the binary incompatibility goes? I will be searching for a solution, but in the meantime I thought I would ask here since someone would have been bound to have encountered this issue before.

Have you checked /usr/lib to see if libstdc++.so.6 is there?

On my red hat machine at work libstdc++.so.6 is actually a simlink to libstdc++.so.6.0.3

Whats happening is that when you run the program the linker is trying to find the necessary shared libraries but it is unable to find libstdc++.so.6 so it errors out.

Yep, but my point was that some systems won't have it, and in the future, my own system might make use of a later version that isn't compatible. How do I make sure I can still play my game without the need to recompile just because a new version of GCC was released?

Well, I think I found the answer:

http://www.trilithium.com/johan/2005/06/static-libstdc/

I tried it with my own project, and so far it seems to work on a number of my systems. It adds a bit more to the download, but not too much. I think it was 0.5MB extra.

Apparently it isn't the only solution, so I'm open to hearing what other people have to say about how they handled this issue.

EDIT: Added hyperlink-ability.

[Edited by - GBGames on December 9, 2005 3:45:30 PM]

One option is to distribute all the shared libraries you use with your program and during installation write a script into /usr/local/bin that puts your program's library directory in the shared library search path. See man ld.so for more about how shared libraries are searched for.

Did you try to compile with "-fabi-version=1" to force selection of an earlier libstdc++ ?

Read here:
http://gcc.gnu.org/onlinedocs/libstdc++/abi.html
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/C_002b_002b-Dialect-Options.html#index-fabi_002dversion-123

Thanks for the info! I'll look into it.