Author Topic: How to avoid - /usr/lib/libstdc++.so.6: version `GLIBCXX_x.x.x' not found ...  (Read 12636 times)

softcoder

  • MegaGlest Team
  • Battle Machine
  • ********
  • Posts: 2,239
    • View Profile
Do any of the nix dev's know what I'm talking about? I've got Ubuntu 8.1, 9.04 and 9.10 in this house and i DON'T want to be compiling for each box with another version of stdc++.

I'll investigate a solution if need be, but wanted to know if there is anyone here who knows a solution?

Thanks

titi

  • MegaGlest Team
  • Airship
  • ********
  • Posts: 4,240
    • View Profile
    • http://www.titusgames.de
I made all the last releases for normal glest.
The secret from what i know is
1. use an old linux distribution to build the binary: ( I'm building on ubuntu 8.04 but if needed i can also build on ubuntu 6.06 )
2. include all libs which are needed ( not realy all, look at my release below it contains the usually missing ones )

Latest linux beta from sourceforge ( with readme ,libs and startscript  ):
http://sourceforge.net/projects/megaglest/files/megaglest3.2.4-4-beta1_i386_linux_bin.tar.bz2/download
There is one thing I still cannot fix perfectly, this is the libopenal problem mentioned in the readme file.

I cannot include libopenal with the binary, because newer versions support newer hardware and they are compatible and work with the binary. :/

To know which libs are needed by a binary you can use the command "ldd" in linux.
ldd glest.bin    lists you all glest needs

If its ok for you I would be very happy to continue building the "official" linux32 bit binarys.
Try Megaglest! Improved Engine / New factions / New tilesets / New maps / New scenarios

softcoder

  • MegaGlest Team
  • Battle Machine
  • ********
  • Posts: 2,239
    • View Profile
Yes I see that is one way that people deal with compatibility. We'll leave it up to Titi to do official linux 32 builds for Mega-glest.

There is the option static linking (making one big binary) but that seems to have loads of reasons why people don't do it and I'm not sure it would work for Glest anyways.

For now I'll finish doing a release build for win32, then cleanup the project files, then build a linux 64 bit version.

Thanks

silnarm

  • GAE Team
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
Yeah, not generally advised apparently...

possible,
http://www.trilithium.com/johan/2005/06/static-libstdc/
but doesn't look like fun :)

For now I'll finish doing a release build for win32, then cleanup the project files, then build a linux 64 bit version.

I sent some vc project files to titi a while back, they are well configured, but need a few unused things stripped out of a couple of files in the shared_lib, I hinted that he should add them to the repository, but he never did :-\

I can build you a x86-64 binary for linux, is the code on SVN up to date?
Glest Advanced Engine - Code Monkey

Timeline | Downloads

softcoder

  • MegaGlest Team
  • Battle Machine
  • ********
  • Posts: 2,239
    • View Profile
Yes the code in SVN is up to date. If you could build a x64 binary, I'm sure Archmage (and others) would love it.

Re: Win32, go ahead and send me any project files you have (they may come in handy). I've got the win32 source for Xerces 3.0, wx 2.8 and mega-glest. Between all these I'm going to try a static build of glest (to avoid the same dll insanity we see in nix... only worse due to the whole manifest stuff with VC++).

Thanks

softcoder

  • MegaGlest Team
  • Battle Machine
  • ********
  • Posts: 2,239
    • View Profile
Ok at some point I'll be trying to get this:

http://www.kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html

to work. I have experience cross compiling for my linux based router's (I use Tomato firmware and wrote my own bandwidth monitor add-on).

If I can get it to work it should solve most issues with dependencies in linux.

titi

  • MegaGlest Team
  • Airship
  • ********
  • Posts: 4,240
    • View Profile
    • http://www.titusgames.de
I don't really get it, why should it fix the library problems? Is this not just a possibility to create binaries for another system ?
Please explain it a bit.
Try Megaglest! Improved Engine / New factions / New tilesets / New maps / New scenarios

softcoder

  • MegaGlest Team
  • Battle Machine
  • ********
  • Posts: 2,239
    • View Profile
Yes cross compiling lets you build for another system.. but that is not all! It allows you to use different versions of libraries (like older gcc++ etc) which is essentially the same as running an old Ubuntu server but without having to have another server installed.

Thanks

RedDwarf

  • Guest
I don't have access to a Linux system right now. But this is because gibc uses symbol versioning.

There is really no other way than using older libraries (or perhaps use apgcc, from autopackage.org). But *some* of the newer symbols are there because of security features that, if disabled, will lower the requirement of the glibc version. You can disable some of them using the "-fno-stack-protector" gcc flag. Also, with the classic ELF examination utils (objdump, readelf, etc.) you can see the minimum version of glibc your binary requires.

Edit: OK, now I have my Linux system...

Code: [Select]
$ objdump -p glest.bin | fgrep 'Version References:' -A 100
Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 17 GCC_3.0
  required from libpthread.so.0:
    0x09691a75 0x00 10 GLIBC_2.2.5
  required from libjpeg.so.8:
    0x04cdfde0 0x00 08 LIBJPEG_8.0
  required from libpng14.so.14:
    0x052a4a70 0x00 06 PNG14_0
  required from libm.so.6:
    0x09691a75 0x00 04 GLIBC_2.2.5
  required from libc.so.6:
    0x06969191 0x00 14 GLIBC_2.11
    0x0d696914 0x00 13 GLIBC_2.4
    0x09691974 0x00 11 GLIBC_2.3.4
    0x0d696913 0x00 09 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x09691a75 0x00 03 GLIBC_2.2.5
  required from libstdc++.so.6:
    0x0297f861 0x00 16 GLIBCXX_3.4.11
    0x02297f89 0x00 15 GLIBCXX_3.4.9
    0x0297f864 0x00 12 GLIBCXX_3.4.14
    0x056bafd3 0x00 05 CXXABI_1.3
    0x08922974 0x00 02 GLIBCXX_3.4
As you can see my binary requires glibc 2.11 and the version of gcc (that provides libstdc++) that provides GLIBCXX_3.4.14. Looking at http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html that's version 4.5.0.

And those requirements comes from this symbols:
Code: [Select]
$ objdump -CT glest.bin | grep -e GLIBCXX_3.4.14 -e GLIBC_2.11
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.14 std::_List_node_base::_M_unhook()
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.14 std::_List_node_base::_M_hook(std::_List_node_base*)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.14 std::_List_node_base::_M_transfer(std::_List_node_base*, std::_List_node_base*)
0000000000490330      DF *UND*  0000000000000000  GLIBC_2.11  __longjmp_chk
How to remove those symbols may require some Google, "-fno-stack-protector" continues being the first option.

If you can remove also these:
Code: [Select]
$ objdump -CT glest.bin | grep -e GLIBCXX_3.4.9 -e GLIBCXX_3.4.11
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.9 std::ostream& std::ostream::_M_insert<bool>(bool)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.11 std::ctype<char>::_M_widen_init() const
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.9 std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.9 std::ostream& std::ostream::_M_insert<double>(double)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.9 std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
The libstdc++ requirement will be lowered to gcc 3.4.0. Old enough (year 2004) and unavoidable since this version is totally incompatible with older versions.

The official binary requires glibc 2.7 and gcc 4.4 (21-04-2009), if needed probably could be improved.
Other libraries usually don't version symbols and is more difficult to know the minimum version.

When creating binaries that you want to be so compatible as possible you also must be sure you are not creating unneeded dependencies.
This is my binary:
Code: [Select]
$ readelf -d glest.bin | fgrep NEEDED | sort
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGL.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGLU.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libjpeg.so.8]
 0x0000000000000001 (NEEDED)             Shared library: [liblua.so.5.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libopenal.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpng14.so.14]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libSDL-1.2.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libvorbisfile.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.0.so]
and this is the binary from the official "megaglest3.4.0_i386_64_linux_bin.tar.bz2":
Code: [Select]
$ readelf -d glest.bin | fgrep NEEDED | sort
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGL.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGLU.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libICE.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libidn.so.11]
 0x0000000000000001 (NEEDED)             Shared library: [libjpeg.so.62]
 0x0000000000000001 (NEEDED)             Shared library: [liblber-2.4.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libldap_r-2.4.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [liblua5.1.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libogg.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libopenal.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpng12.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libSDL-1.2.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libSM.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libvorbisfile.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libvorbis.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libxerces-c.so.28]
 0x0000000000000001 (NEEDED)             Shared library: [libXext.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]

Mine depends on 16 libraries and the official one on 25. And mine have an extra one (libcurl) since I patched the build system to use the shared version. So the official binary has ten dependencies that are not really needed:
Quote
0x0000000000000001 (NEEDED)             Shared library: [libICE.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libidn.so.11]
0x0000000000000001 (NEEDED)             Shared library: [liblber-2.4.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libldap_r-2.4.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libogg.so.0]
0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libSM.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libvorbis.so.0]
0x0000000000000001 (NEEDED)             Shared library: [libXext.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
Even if those libraries are not used, the binary will refuse to work if they are not available in the user system... or if they are available but with different sonames.
The easy way to remove them is to use the "--as-needed" ld flag (so "-Wl,--as-needed" in gcc), but you require a ld version recent enough to support it. Otherwise you must fix the build system... complex since the problem sometimes isn't in your build system but in the build system of a (really) dependent library.

Also, the official binary uses shared libraries that are included in the "lib" directory. Since these "shared" libraries are not really shared it's better to static link to them because it's faster.
« Last Edit: 15 February 2011, 21:24:50 by RedDwarf »