strlen runtime error on Ubuntu - c++

I develop a CGI C++ application that I compiled under Debian. Running this app on an Ubuntu system I am getting the error:
relocation error: /lib32/libresolv.so.2: symbol strlen, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
What can I do now? Should I recomile on the Ubunto system? Can I replace a library?
Edit
I link my application with -static.
Running the command ldd --version on the Ubuntu system showed my that EGLIB is used there.

What this error means is that your program was compiled/linked against an older version of GNU libc, which is not supported on the system where you want to run your executable.
You have few options to solve it:
Make sure you use the same or compatible version of libc when compiling and running.
Link against a static runtime.
Install older version of libc on Ubuntu system to match the Debian's environment.

Related

This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.5.0)

When I copy my executable and lib dependencies to another computer and run the program I get this error:
This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.5.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library.
This error only happens in the new computer. I can run my program on my computer without any issue.
I tried to check with ldd -d and objdump -p engine | grep NEEDED which of the libs are that have protobuf in them, but I can't find them.
My program uses: opencv with Cuda, boost, tensorflow, tensorRT.
Both of the computer OS is Ubuntu 16.04.6 LTS.
How can I find which part has the issue with this conflict?
I tried to recompile opencv without protobuf by adding -DBUILD_PROTOBUF=OFF -DPROTOBUF_UPDATE_FILES=ON -DPROTOBUF_INCLUDE_DIR=/usr/include -DPROTOBUF_LIBRARY=/usr/lib/x86_64-linux-gnu/libprotobuf.so.
This did not solve the issue.
You have two different version libprotobuf, with one installed in /usr/local/lib/ by dynamic library.
But when you build your program, you include other version of libprotobuf.
You can reinstall libprotobuf to solve this question.
If you install libprotobuf from source, make sure you added the flag -Dprotobuf_BUILD_SHARED_LIBS=ON.

Build for older glibc

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.

Wrong GLIBCXX version when running a program that was compiled on the same machine

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.

Build with gcc for systems with older gcc

Hi I am trying to build an executable on Ubuntu for RedHat 6.4 - and I am struggling due to the different gcc versions.
The RedHat 6.4 machine uses gcc 4.4.7. The Ubuntu machine uses gcc 4.6.3.
Here is what I have tried:
Install g++-4.4 on the Ubuntu machine and compile with older version of gcc: failed because the code base uses features not yet available in g++-4.4
Copy the Ubuntu libc.so.6 and libstdc++.so.6 over to the RedHat machine. The program sort of gets started, then segfaults.
Link the executable on Ubuntu statically with -Wl,-Bstatic as link options. Failed on a third party library with "warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking".
So I am a bit stuck now... Any advice?
Based on comments above, decided to dump RedHat (didn't have a subscription, so not easily upgradable) on the other machine and switch to Fedora, which has the latest gcc. Not a solution that scales, but what can you do.

How can I work out why a specific version of a library is in the dependencies?

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.