I have created c++ application in Ubuntu machine. I have copied binary to Centos machine. Got error:
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
I decided to check which versions of glibc I have in my machines with help of ldd --version command:
Ubuntu: 2.23
Centos6.9: 2.12
Why CentOS cmplains regarding GLIBCXX_3.4.21, while Ubuntu owns glibc version 2.23?
The symbols like GLIBCXX_3.4.21 are generated by the compiler to mark which version of the C++ library that the compilation was used with (in particular, non-inline functions called from header-files & template functions). This is the libstdc++ library, not glibc.
The version that you are looking for is your libstdc++ - and this is one of the interesting problems with C++, the template library tends to change every now and again, so a function may be declared as unsigned int func(), and later someone decides to change it to size_t func(). No difference in 32-bit machines, but for 64-bit machines it DOES make a difference, and using the "wrong" version will lead to problems with the size of the return value.
There are a few different solutions (and this is not a complete list):
Make sure you use the same version of libstdc++ on both machines.
Compile the code on the target machine.
Use static libstdc++
This a great - I used the -static option in the link and it solved by problem also.
Related
[Situation]
I'm developing a c++ library. I had a issue with the GLIBCXX version.
Before, I developed on version machine GLIBCXX_3.4.22.
But my library is not working on the target machine which has GLIBCXX_3.4.19.
So, I downgraded gcc version from 5.2.x to 4.8.x and GLIBCXX version from 3.4.22 to 3.4.19.
It successfully ran on the target machine.
But my development machine(ubuntu) boot fails because other libraries can't find GLIBCXX 3.4.22 version which is already linked to that version.
So, I re-installed GLIBCXX 3.4.22 but gcc version is still 4.8.5.
[Question]
Does my library compiled on gcc-4.8.5 not use GLIBCXX_3.4.22 version? Is it fine to develop on this environment (gcc 4.8.5, GLIBCXX_3.4.22)?
What is the relationship between gcc(compile) version and GLIBCXX(GLIBC) version on the linux machine.
Where can I check the correct version compatibility mapping information between gcc and GLIBCXX(GLIBC)?
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.
I'm running CentOS 6.4 and need a later version of the C++ compiler to build my development tools (Qt Creator in this case).
I'm unclear on the implications of using devtools and I'm hoping someone can explain.
If I compile programs using devtools, does that means the executable will run on other Centos 6.4 installations without change?
Or..do I know have to ship libraries or other files with my compiled programs?
If so...do I have to modify my C++ code to reference the later libraries? or is this something done by the person installing my compiled program
I hope this somewhat late answer can still help you. What I found is that compiling my project with devtoolset (1.1 in my case, but that should not matter too much) on RHEL 6.4 produces binaries which can almost run on a standard RedHat EL 6.4 (should be similar for Centos 6.4).
The only trouble I ran into was compiling my project with -std=c++11, which produced some problems due to incompatible symbols. The reason is that the GCC folks considered these parts of the standard library to be experimental in GCC 4.4, so they broke ABI compatibility in some places.
Turns out, there's an easy fix: Link your programs with the additional command-line-argument -static-libstdc++. That way, the binary becomes a bit larger but is runs on an unmodified RHEL 6.4 without installing additional libraries/updates for the devtoolset.
To answer your questions explicitly:
Yes, almost.
No.
Don't change the code, just add -static-libstdc++ when linking.
Generated an executable on Linux 32-bit Ubuntu 11 and tested it on a 32-bit Ubuntu 10 and it failed with a "GLIBC_2.15" not found.
Cyrhon FAQ section says:
Under Linux, I get runtime dynamic linker errors, related to libc. What should I do? The executable that PyInstaller builds is not
fully static, in that it still depends on the system libc. Under
Linux, the ABI of GLIBC is backward compatible, but not forward
compatible. So if you link against a newer GLIBC, you can't run the
resulting executable on an older system. The supplied binary
bootloader should work with older GLIBC. However, the libpython.so and
other dynamic libraries still depends on the newer GLIBC. The solution
is to compile the Python interpreter with its modules (and also
probably bootloader) on the oldest system you have around, so that it
gets linked with the oldest version of GLIBC.
and
How to get recent Python environment working on old Linux distribution? The issue is that Python and its modules has to be
compiled against older GLIBC. Another issue is that you probably want
to use latest Python features and on old Linux distributions there is
only available really old Python version (e.g. on Centos 5 is
available Python 2.4).
I am starting with IGPROF for memory profiling--
i installed it and done all the steps defined in - http://igprof.sourceforge.net/install.html
but when i am running:
c++ -o vvvi-build-and-copy vvvi-build-and-copy.cc -ldl -lpthread
i am getting error-
c++: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by c++)
i google it but not getting what should i do?? i am using ubuntu right now.
Can you help me ?? plz tell me if you need any other info
Thanks in advance....
It usually means that you are using library compiled by newer compiler (gcc) than you are currently running. You need to recompile library with your current compiler or change to newer compiler.
You do not say what version of Ubuntu. Anyway, the problem is caused by a glibc version mismatch between your C++ and the version installed in Ubuntu.
Run the command
/lib/libc.so.6
to get information on your system's glibc, to confirm. You will see something which is not "version 2.11" as your installed C++ requires.
Your situation may occur if you did an incomplete update of the distribution (i.e., glibc is older than C++ expects, because you forced an update to C++ but left glibc behind).
The best solution should be to do an "apt-get upgrade" of the "old" packages ("apt-get upgrade glibc"), or even update the whole distribution.
Note: this probably has nothing to do with igprof installation, which is unlikely to have modified C++, much less glibc.
I'm building a large C++ project using cmake on ubuntu 12.04 and then taking the resulting binary package and trying to run it on ubuntu 11.04. However the program fails saying it needs glibc version 2.14 but can only find up to version 2.13.
How can I find out exactly why glibc=>2.14 is required?
Unlike most libraries, glibc versions its symbols. Every symbol is tagged with a value (e.g. "GLIBC_2.3.4") representing the version of the library where it's interface was last changed. This allows the library to contain more than one version of a given symbol and support binaries compiled against older versions while preserving the ability to evolve. You can see this detail with objdump -T /lib/libc.so.6.
Basically, something in your app was linked against a symbol that was changed since 11.04. Try objdump -T on your binary and see what tags it's looking for.
But broadly, backwards compatibility doesn't work like that in Linux. If you want something to run on older software, you should build it on older software. It's possible to set up a backwards-compatible toolchain on more recent distros, but it's not the default.
When you build your C++ project, it will link to the version of the glibc library on your 12.04 installation. What are the linker options in your build command?
Without knowing exactly what you are building, I'd say you might be better off building on 11.04 and then running on 12.04.