Glibcxx Versions

GLIBCXX versions

Use readelf -a and objdump -x to inspect ELF files in preference to strings.

Actually, all the GLIBCXX_* versions don't apply to the entire library, but to each symbol (symbol versioning, see DSO-howto). So you can have e.g: std::char_traits<wchar_t>::eq@@GLIBCXX_3.4.5 and std::ios_base::Init::~Init()@@GLIBCXX_3.4 on the same library file.

The fact that your program needs GLIBCXX_3.4.9 probably means that it has been linked against a symbol that has been introduced/has changed semantics on GLIBCXX_3.4.9.

Relationship between GLIBCXX(libstdc++.so.6) and gcc version

libstdc++ (which is where the GLIBCXX_* versioned symbols are from) has been ABI compatible from GCC 3.4.0 to now.

Your library will use the latest symbol versions from libstdc++ at the time of compile. The compiler version does not matter, except
GCC 5.1 added C++11 support with a "dual ABI" in libstdc++. Code compiled in C++11 mode will use symbols with the [abi:cxx11] tag, and that may not interoperate with code compiled without C++11 (whether from an older compiler without C++11 support, or a newer compiler set to use an older standard).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

If you need to build binaries that run on older systems, I would recommend setting up an older distribution inside a container and building in there, with all old libraries. This way, nothing newer from your development system can leak into them.

/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

I'm compiling gcc 4.6 from source, and apparently

sudo make install

didn't catch this one. I dug around and found

gcc/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.15

I copied it in to /usr/lib and redirected libstdc++.so.6 to point to the new one, and now everything works.

Cross compile for specific CXXABI and GLIBCXX version

You'll need to find a compiler of the same version as the target's libstdc++ was part of.

These ABI versions sometimes (not always) increase when new symbols are added to libstdc++.

Your best bet is in any case always to install the same OS version on your build machine. That is guaranteed to have the same toolchain version (although cross-compilers might differ there slightly).

Old answer follows. There is no package for GCC-4 so you'll have to install an older Ubuntu version.

It seems Ubuntu 18.04 has several GCC versions:
https://packages.ubuntu.com/search?keywords=arm-linux-gnueabihf&searchon=names&suite=bionic§ion=all

I'd try the newest one that works for your target. You can also compare the so version of libstdc++.so.X.Y.Z and make sure you use a GCC version with libstdc++ so version of maximum the one on your target machine.

If you're curious, the file defining these symbol versions can be found here: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/config/abi/pre/gnu.ver.

Looking further in that file, I found this commit: https://github.com/gcc-mirror/gcc/commit/c19175577e1cbf749590889441ad5dd03bb2c9d7
It adds the version of symbols you are missing, and Github marks this as being present in GCC 5. Unfortunately, Ubuntu 18.04 does not have a pre-5 GCC toolchain.

Where can I find GLIBCXX_3.4.29?

After building GCC and installing the binaries, the softlink /usr/lib/x86_64-linux-gnu/libstdc++.so.6 wasn't updated to the latest version. Mine was still pointing to a previous version as mentioned in the comments above. Under GCC build directory I found the GLIBCXX_3.4.29 build directory and copied the library to /usr/lib/x86_64-linux-gnu and updated the softlink.

libstdc++ GLIBCXX version errors

It seems you are using the standard library as a shared library (default behaviour) when linking your program at home.

So rather than really "linking" the library, your linker just resolves some symbols and does another operation, while delaying the actual loading of the library to run-time.

When you execute your program at your university computer, the loader (the program which actually loads your program in memory and throws the main thread) looks for the libraries your program needs and tries to load them (look for LD_LIBRARY_PATH in linux if you feel curious).

The problem here is that you are linking your program at home with a version of the stdlib that is not the same version as what you have at the university. So when the loader tries to find the library, it fails, and so your program cannot be run.

Solutions:

a) To avoid all these problems use static linking instead of dynamic linking. I am not sure if this is possible with stdlib, but I think it is worth to test it (see: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html and look for "-static" flag)

b) You can try to compile your program at your university computer so it will use the version there.

c) Try to know which stdlib version is installed there and install the same version in your compiler machine.

d) You can try to copy your home version of stdlib to the same folder your application is. This usually works because the loader tends to search for shared libraries in the current application folder before looking in the path set in the environment variable LD_LIBRARY_PATH (linux)

Hope that helps.

P.S.:
Here you have a nice introduction to static vs shared/dynamic libraries http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html

And here (http://en.wikipedia.org/wiki/Library_%28computing%29) a not so nice but more complete library description.

Glibcxx Versions