[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#325226: libc6: Wrong dynamic linker on amd64

Andreas Jochens a écrit :

Hi !

thanks for applying the patch the glibc SVN! I have a heavily used amd64 system running with a glibc that has been built with this patch and it works fine so far.

However, I also built an amd64 installer image with the libc6-udeb package from the patched glibc and this fails with the following error message:

/usr/bin/main-menu: error while loading shared libraries: libdebconfclient.so.0: cannot open shared object file: No such file or directory

This occurs because the patch changes the default library search path
of the dynamic linker from "/lib /usr/lib" to "/lib64 /usr/lib64".

Well it's already strange it has works before. The dynamic linker path on amd64 is /lib64/ld-linux-x86-64.so.2, and most of the binaries seems to use this path. However it seems that a few binaries and libraries are using /lib/ld-linux-x86-64.so.2. This is wrong.

What it is strange is that d-i works without problem, which would mean all librairies and binaries are using the /lib/ linker. Just try to remove /lib64 on your computer, even with the unpatched glibc, you will see that it is completly broken.

I found this by doing a

grep lib64 /lib/ld-linux-x86-64.so.2

which fails for the unpatched glibc 2.3.6-1 and succeeds for the patched one.

The 'libdebconfclient.so.0' file is installed in /usr/lib and the installer does not have a symlink from /usr/lib64 to /usr/lib.
Consequently, the dynamic linker does not find that library.

To fix this, I suggest to add the missing symlink /usr/lib64 -> /usr/lib
to the 'libc6-udeb' package in debian/sysdeps/amd64.mk in a similar
way as it is done for the 'libc6' package.

Fixed in SVN.

Additionally, I think that the default library search path of the dynamic linker should be changed back to the currently used "/lib /usr/lib" because this is where the libraries are really installed. But I did not yet find a simple way to achieve this.

Well as explained before we must have the link anyway, so I think it is enough. I also don't have any idea how to do that, the linker path and the search path are linked together. We can probably add new search path /lib and /usr/lib, but I don't know the consequences, are the libraries will be seen twice. That would probably make the ldconfig cache greater.

I also have two more suggestions for debian/sysdeps/amd64.mk:

-libc_extra_cflags = -O3
+libc_extra_cflags = -O3 -g1
-libc_extra_config_options := $(extra_config_options) --with-tls --with-__thread

The '-g1' was removed from libc_extra_cflags some time ago as a hack to avoid a problem with gcc-3.4 which has been fixed in gcc-4.0.

The libc_extra_config_options line can be dropped because the '--with-tls' and '--with-__thread' options are the defaults
since glibc version 2.3.5.

Ok, I will fix that


  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: