Andreas Jochens a écrit :
Hello,
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
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`- people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
