I'm building 32 bit c++ library that will run on old system on modern Ubuntu machine. Application works fine on Ubuntu, but when I moved to old Centos 6.9 machine I got error:
Failed to open my lib: /usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by /home/aaa/bbb/libme.so)
How to solve this problem? How to build for older glibc?
The only way to tell the compiler and linker to use older symbol
versions is by using linker scripts. However, this requires you to
specify the version for each and every symbol, which is an undoable
task.
You can use Holy Build Box
Holy Build Box solves the glibc symbol problem by providing a
tightly-controlled build environment that contains an old version of
glibc.
Related
I am building a build environment for some cross compiled embedded sw, it is quite old, so when compiling in Ubuntu 16.04, I get a conflict, that is "redefinition of struct timeval". I was comparing time.h from old systems, I figured out timeval structure was not yet in the old libc, is it possible for me to downgrade libc?
unfortunately, no, you cannot downgrade the C library in your distro. all the other programs in your system were compiled against that new version, so trying to downgrade it will break everything (literally everything --
like basic programs of ls and mv and such).
you can either fix your old source project, or find an old release of a distro (like Ubuntu) and install it in a VM.
How is it possible that a program that I compile, link and run on the same machine to have GLIBCXX version errors when I try to run it? Does anyone know?
Here is the error I am getting:
0.01s$ build/test/gamgee_test
build/test/gamgee_test: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by build/test/gamgee_test)
build/test/gamgee_test: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by build/test/gamgee_test)
full output (with VERBOSE=1) including building and running is here:
https://travis-ci.org/broadinstitute/gamgee/jobs/39751787
This wasn't happening before, only after I switched to cmake. Also the same code runs fine with Clang (using a bundled version of libstdc++ since I haven't installed libc++ on the VM). That log is here: https://travis-ci.org/broadinstitute/gamgee/jobs/39751786
very puzzled.
Runtime paths are different to compile paths. Sounds like you have more than one version of your libraries on your system. check your LD_LIBRARY_PATH env variable and call your executable with ldd to see what libraries it is using/trying to use.
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'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.
I am trying to deploy my application from development environment to users' computer, but I have some issues.
First, I compile and run it on my development computer (higher version Ubuntu11.04):
Ubuntu11.04$ make
Ubuntu11.04$ ./MyApp
Program runs okay.
Then I copied the binaries MyApp to two lower-version machines (users' computer):
Ubuntu10.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
Ubuntu8.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./MyApp)
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
However, if I compile the source code on Ubuntu10.04, and run it:
Ubuntu10.04$ make
Ubuntu10.04$ ./MyApp
Program runs okay.
What should I do with this? When I compile it in development environment, how can I set the version number of the used library? I'm not directly using GLIBCXX, I think it's being used implicitly somewhere in my project.
Thx a million.
Peter
Did you see Link with an older version of libstdc++
I have never installed an older version of g++, but I have included a libstdc++.so in my release and that has worked for me. Best solution I have seen is get your development stuff to work on the oldest possible system. We compile some stuff on Red Hat 9 and it work on everything, but it can be any major issue building on old machines as you say.
You have built on version N, and tried to deploy on version M, M<N. You will need to get the deployment computer upgraded, or learn the procedure to compile and link targeting an older version. Since the problem lives in libstdc++, I'm afraid that my advice is to downgrade your entire dev system or upgrade the target, libstdc++ is not easy to deal with. Another answer here has someone's recipe.
Keep in mind that the Ubuntu/Debian community is optimized for open source. From their point of view, the solution to this is for you to distribute source code with the auto* tools, and let the user built it for him or her-self. They don't stay up late making this easy for you.
Here in the evil world of closed source, we keep around VMs running all sorts of old linux distros just so that we can build a single binary that runs in many places.