I have a simple hello_world.cpp program. I compiled it using g++4.4.7 on a CentOS 6.6 system. When I look at ldd a.out:
linux-vdso.so.1 => (0x00007fffbd79e000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ab6f6819000)
libm.so.6 => /lib64/libm.so.6 (0x00002ab6f6b1f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ab6f6da4000)
libc.so.6 => /lib64/libc.so.6 (0x00002ab6f6fba000)
/lib64/ld-linux-x86-64.so.2 (0x00002ab6f65f7000)
When I load a module for gcc-4.9.2, LD_LIBRARY_PATH is set to /path/to/gcc-4.9.2/lib64 and running ldd a.out yields :
linux-vdso.so.1 => (0x00007ffff9393000)
libstdc++.so.6 => /path/to/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b2b7c104000)
libm.so.6 => /lib64/libm.so.6 (0x00002b2b7c435000)
libgcc_s.so.1 => /path/to/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b2b7c6b9000)
libc.so.6 => /lib64/libc.so.6 (0x00002b2b7c8cf000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2b7bee2000)
QUESTION : Why is the 4.9.2 version of the gcc libraries used when LD_LIBRARY_PATH is set, even though I compiled with with 4.4.7?
This seems to pose a problem of knowing which version of a library is being used. A user may compile a program with one compiler version, load a different compiler versions (via module) and then run the executable which uses a different library version than expected.
I don't know whether you're aware that the use of Environment Modules
is not a necessary or normal part of using GCC, or even using multiple versions of GCC.
Setting LD_LIBRARY_PATH to override the system dynamic linker's default directory search order
is a practice that has been long and loudly censured, for reasons that include the
one expressed in the last paragraph of your post. See e.g. Gurus say that LD_LIBRARY_PATH is bad
Doing so within environment modules in a system tailored for the use of multiple versions of tools or toolchains
can be regarded as a regulated application of a hazardous practice. In that context, however, the
setting of LD_LIBRARY_PATH in your gcc-4.9.2 environment module is doing exactly what
such a setting is supposed to do: overriding the
dynamic linker's default directory search order. See the documentation: 3.3.1.
In principle it is possible that a program compiled and linked with an older or
later version of GCC would behave unexpectedly if you choose to run it in the
environment of the gcc-4.9.2 module. Environment modules are a niche convenience,
and they come with this risk. Although if you built the program in the native
environment, or specifically in a module-enabled environment for gcc 4.4.7, then
the risk attendant on running it in your gcc-4.9.2 environment is presumably one
that you don't have to take.
Related
I'm working on an AlpineLinux (installed on my computer, not into a docker) and I'm trying to use a shared library which depends on glibc.
As Glibc isn't integrated into this distribution, I saw that an alternative, gcompat, was developed to provide a compatiblity with programs that were built for Glibc.
The library I want to use is the IDS Imaging's driver (for their camera).
When loading dynamically the .so with CDLL (from a python script), it fails.
After this fail, I ran ldd libueye_api.so to check if all dependencies were found and I got :
/lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fb684d93000)
librt.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
libpthread.so.0 => /lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7fb684d51000)
libm.so.6 => /lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fb684d38000)
libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7fb685c50000)
ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7fb684d32000)
Error relocating libueye_api.so: __pthread_register_cancel: symbol not found
Error relocating libueye_api.so: __pthread_unregister_cancel: symbol not found
In this log I see that musl and gcompat were successfully found but __pthread_register_cancel and __pthread_unregister_cancel were not found...
Someone has an idea to solve this issue ?
AlpineLinux uses MUSL instead of GLIBC. MUSL is lighter and doesn't drag a legacy with it. This is a problem when applications depend on the legacy, like when they want to use pthread.
AlpineLinux has a wiki that describes 4 alternatives for running applications that require GLIBC.
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
One of the options is to use the gcompat package from a community contribution. The APK package, description and other details are on the pkgs pages
https://pkgs.alpinelinux.org/packages?name=gcompat&branch=edge&repo=community&arch=x86_64
In the APKBUILD file it shows where the source code come from and the pthread in the compat lib does not have __pthread_register_cancel. In your stacktrace I don't see any reference to /lib/libgcompat.so.0, so maybe the library still needs to be found, by running ldconfig, but I think gcompat does not contain all pthread methods. It just isn't in the code
https://git.adelielinux.org/adelie/gcompat/-/blob/current/libgcompat/pthread.c
I vaguely remember that I once installed GLIBC packages in AlpineLinux, but that may just have been one of my crazy dreams, I can't find such package in the repositories
What I do find is an APK and Docker image by Sasha Gerrand, who created a full GLIBC 2.34 library for AlpineLinux. If you install the APK package or use the Docker image, you should have a full glibc running on AlpineLinux.
https://github.com/sgerrand/alpine-pkg-glibc
Personally I would try to avoid running applications that are so library dependent, but I understand it sometimes isn't a choice to switch to something more flexible.
I have installed another version of GLIBC and want to compile Golang code against this new GLIBC.
I have tried the following command for dynamic compilation:
go build --ldflags '-linkmode external -L /path/to/another_glibc/
But when I run ldd "go_executable", it still shows linked to default glibc.
Output:
linux-vdso.so.1 => (0x00007fff29da7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f128a93c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f128ad06000)
Expected Output:
linux-vdso.so.1 => (0x00007fff45fa7000)
libc.so.6 => /another_glibc/lib/libc.so.6 (0x00007f5cd2067000)
/another_glibc/ld-2.29.so => /lib64/ld-linux-x86-64.so.2 (0x00007f5cd2420000)
What is missing here?
This is not an answer to the question, just a warning:
If you, like me, came here because you were compiling to deploy on another machine and got "version `GLIBC_2.32' not found" (or similar), but you were not intentionally using CGo, stop here.
Go on Linux dynamically links C libraries to have faster and smaller builds, but it is able to supplement them for example when cross-compiling.
You can do export CGO_ENABLED=0 to disable CGo and get rid of the dependencies.
Before doing go build
Set
CGO_LDFLAGS
Dynamic:
export CGO_LDFLAGS="-Xlinker -rpath=/path/to/another_glibc/lib"
Static:
export CGO_LDFLAGS="-Xlinker -rpath=/path/to/another_glibc/lib -static"
CGO_LDFLAGS lets you set GCC-like ld flags for Go.
bitbyter's answer is not correct for the dynamic case because it requires that the system dynamic linker is compatible with the non-system glibc, which is unlikely. You can set the dynamic linker like this:
export CGO_LDFLAGS="-Xlinker -rpath=/path/to/another_glibc/lib64"
CGO_LDFLAGS="$CGO_LDFLAGS -Xlinker --dynamic-linker="/path/to/another_glibc/lib64/ld-linux-x86-64.so.2"
The dynamic linker name is specific to the architecture, so you have to research its name.
I'm trying to build a project using a static library, so that the binary can be used even if the library isn't installed. However, I get lots of errors about undefined symbols when I try to do so.
Looking at the library, I see it has tons of undefined symbols, even though it's a .a static lib:
nm - u /usr/local/lib/libthis.a
....
U EVP_DigestFinal_ex
U EVP_DigestInit_ex
U EVP_DigestUpdate
U EVP_MD_CTX_cleanup
U EVP_MD_CTX_init
Those seem to be from openssl; others seem to be from libbzip2; etc.
Questions:
1. Why does the static (.a) lib have dependencies on shared objects (e.g. libopenssl) that aren't statically compiled?
2. How do I solve this? Trying to manually add -lssl doesn't seem to work. How do I get the binary to compile and not have external dependcies?
Why does the static (.a) lib have dependencies on shared objects (e.g. libopenssl) that aren't statically compiled?
Just about every static library that you can build will have unresolved symbols, e.g.
int my_open_for_read(const char *filename)
{
return open(filename, O_RDONLY); // unresolved reference to open
}
As Marc Glisse pointed out, this a plain unresolved symbol, not a dependency on libc.so.
How do I solve this?
There is no problem to solve here. When you link your binary, you get to decide which libraries to link statically, and which to link dynamically.
Trying to manually add -lssl doesn't seem to work.
This should work:
gcc main.o -lthis -lssl
Possibly you did something like
gcc main.o -lssl -lthis
which is wrong: the order of libraries on the link line matters.
How do I get the binary to compile and not have external dependcies?
Most OSes support using fully-static binaries. Generally this should not be your goal: it makes for less portable binaries, and their use is strongly discouraged.
If you really do want to produce a fully-static binary, link it with -static flag.
Why do you say full static is less portable?
Because they are.
if the user doesn't have the exact same build of the lib, the binary won't be portable with shared libs, but will be portable with static.
This is incorrect: most shared libraries support backward compatibility, e.g. libc.so.6 version 2.22 will happily run executables linked against version 2.3.6 from 10 years ago.
If you do ldd firefox
You need to pay attention to what you are doing:
file -L `which /usr/bin/firefox`
/usr/bin/firefox: POSIX shell script, ASCII text executable
If you look inside the shell script, you'll discover that it invokes /usr/lib/firefox/firefox, and that binary is dynamically linked:
ldd /usr/lib/firefox/firefox
linux-vdso.so.1 => (0x00007ffca278d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f511731b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5117117000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5116e13000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5116b0d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f51168f7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5116532000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5117757000)
I have to compile a program on a current ubuntu (12.04). This program should then run on a cluster using CentOS with an older Kernel (2.6.18). I cannot compile on the cluster directly, unfortunately. If I just compile and copy the program without any changes I get the error message "kernel too old".
The way I understood it, the reason for this is not so much the Kernel version, but the version of libc that was used for compilation. So I tried to compile my program dynamically linking the libc from the cluster and statically linking everything else.
Research
There are already a lot of questions about this on SO but none of the answers really worked for me. So here is my research on that topic:
This question explains the reason for the Kernel too old message
This question is similar but more specialized and has no answers
Linking statically as proposed here didn't work because the libc is too old on the cluster. One answer also mentions to build using the old libc, but doesn't explain how to do this.
One way is to compile in a VM running an old OS. This worked but is complicated. I also read that you should not link libc statically
Apparently it is possible to compile for a different libc version with the option -rpath but this did not work for me (see below)
Current state
I copied the following files from the cluster into the directory /path/to/copied/libs
libc-2.5.so
libgcc_s.so.1
libstdc++.so.6
and am compiling with the options -nodefaultlibs -Xlinker -rpath=/path/to/copied/libs -Wl,-Bstatic,-lrt,-lboost_system,-lboost_filesystem -Wl,-Bdynamic,-lc,-lstdc++,-lgcc_s
The output of ldd on the compiled binary is
mybin: /path/to/copied/libs/libc.so.6: version `GLIBC_2.14' not found (required by mybin)
mybin: /path/to/copied/libs/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by mybin)
linux-vdso.so.1 => (0x00007ffff36bb000)
libc.so.6 => /path/to/copied/libs/libc.so.6 (0x00007fbe3789a000)
libstdc++.so.6 => /path/to/copied/libs/libstdc++.so.6 (0x00007fbe37599000)
libgcc_s.so.1 => /path/to/copied/libs/libgcc_s.so.1 (0x00007fbe3738b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbe37bf3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbe37071000)
I'm somewhat confused by the error, because it uses the correct path (i.e. the libc from the cluster) but still complains about a missing glibc version. When running ldd on the cluster it returns not a dynamic executable and running the binary results in the same two errors mentioned above. It also looks like there are other libraries included (linux-vdso.so.1, ld-linux-x86-64.so.2 and libm.so.6). Should I use the older versions for those as well?
So now I have two main questions:
Is this even the correct approach here?
If yes: how do I link the old libc correctly?
See this answer.
Is this even the correct approach here
No: you can't use mismatched versions of glibc as your link command does. You used crt0.o and ld-linux.so from new (system-installed) libc, but libc.so.6 from an old (copied from cluster) libc. That is just not going to work.
-rpath sets the DT_RPATH tag but doesn't tell the linker to look there for libs, you want -L for that.
I run a cross debug session with GDB. GDB is configured with option --with-sysroot, how described in the docs. My Application uses shared libraries like the following.
Code:
libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
libm.so.6 => /lib/libm.so.6 (0x40046000)
libdl.so.2 => /lib/libdl.so.2 (0x400b9000)
librt.so.1 => /lib/librt.so.1 (0x400c4000)
libts-0.0.so.0 => /usr/lib/libts-0.0.so.0 (0x400d3000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4015f000)
libz.so.1 => /usr/lib/libz.so.1 (0x401d3000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x401ee000)
The libraries pthread, libdl, ... are found in my toolchain, declared by set sysroot, --with-sysroot and set solib-absolute-path
The libraries libts, libz, ... are available in my additional path for shared libraries, declared in session with set solib-search-path
For the libraries libfreetype, libjpeg the following error occurs:
102,416 &"warning: `/usr/lib/libfreetype.so.6': Shared library architecture unknown is not compatible with target architecture arm.\n"
102,416 =library-loaded,id="/usr/lib/libfreetype.so.6",target-name="/usr/liblibfreetype.so.6",host-name="/usr/lib/libfreetype.so.6",symbols-loaded="0",thread-group="i1"
The reason GDB still takes libraries of host rootfs, once not found in the toolchain, and available in host rootfs. It doesn't care about my additional path declared with set solib-search-path
I configured GDB with --with-sysroot, declared additional set sysroot, set solib-search-path, set solib-absolute-path (nevermind alias of set sysroot).
In the docu, --prefix configures GDB to take the sysroot autmatically, but why this is higher prior than --with-sysroot?
Is GDB using the order sysroot, host-sysroot, solib-search-path?
What i missed to tell GDB, not to use the host rootfs?
There is a gdb bug tracking the very same issue http://sourceware.org/bugzilla/show_bug.cgi?id=13989
It is not fixed until version gdb-7.4. So, I think this behavior is expected with previous versions.