Bug#325226: libc6: Wrong dynamic linker on amd64
Andreas Jochens a écrit : Hello, Hi, [..] Yes, without the /lib64 symlink the system breaks in any case because the path to the linker /lib64/ld-linux-x86-64.so.2 - which is hardcoded by gcc into every binary - no longer exists without the /lib64 symlink. But I liked the fact that up to now this was the _only_ thing which really used the /lib64 symlink. I do not like the ugly (/usr)/lib64 directories at all and I think they should be dropped in the long term. Again, this point is just my personal opinion and not really technically important to make things work now. I reverted the changes done in the SVN, and used a modified version from the patch you sent before. Basically my changes are that nothing is hardcoded and no conditional patching is used, as it is possible to change slibdir and rtlddir in the configparams file of the build tree, and directly via sysdeps/*.mk. This patch is also necessary for proper multiarch support, therefore I will send it to upstream. -- .''`. 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]
Bug#325226: libc6: Wrong dynamic linker on amd64
On 06-Feb-15 12:14, Aurelien Jarno wrote: I have just tested a build with your suggested change, and it works correctly. Please find attached the final version of the patch, against the latest SVN. And the patch... +++ debian/patches/series.amd64 (copie de travail) @@ -1,2 +0,0 @@ -amd64-lib.diff -p1 +++ debian/sysdeps/amd64.mk (copie de travail) @@ -18,3 +18,11 @@ ln -sf lib debian/$(curpass)/lib64 ln -sf lib debian/$(curpass)/usr/lib64 endef + +define libc_extra_install +mv debian/tmp-libc/lib64 debian/tmp-libc/lib +mv debian/tmp-libc/usr/lib64/* debian/tmp-libc/usr/lib +for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink $$link | sed -e s#64##g) $$link ; done +for so in $$(find debian/tmp-libc/usr/lib -maxdepth 1 -type f -name *.so) ; do perl -pi -e s#/lib64/#/lib/#g $$so ; done +endef + Hello, 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. 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. 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. 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. Thanks again for your work on the glibc package! Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
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]
Bug#325226: libc6: Wrong dynamic linker on amd64
On Wed, Feb 22, 2006 at 02:45:20PM +0100, Andreas Jochens wrote: 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. The /lib64 - lib symlink on d-i is created by the rootskel.udeb. Please atleast keep things in the same package. I wouldn't have a problem with moving this to the glibc package, and I think we should do that. But we should probably coordinate this with the d-i people. Anyway, I think we shouldn't need a /usr/lib64. The only reason we need a /lib64 is because that is where the dynamic linker is. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
Hello, On 06-Feb-22 20:37, Aurelien Jarno wrote: Andreas Jochens a écrit : 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. I do not think that there are any binaries in Debian amd64 which are using /lib/ld-linux-x86-64.so.2 as the linker path. The official Debian amd64 port always used /lib64/ld-linux-x86-64.so.2 as the linker path as far as I know. Anyway, there seems to be a misunderstanding here. I referred to the default list of paths which are searched _by_ the dynamic linker for libraries in the absence of a '/etc/ld.so.conf' file - not to the path _of_ the dynamic linker itself which is (and always was) /lib64/ld-linux-x86-64.so.2. Your patch has changed the former, i.e. default list of searched library paths from '/lib /usr/lib' to '/lib64 /usr/lib64'. This change can be debated but it _is_ a change to the current status quo nonetheless. As long as the /usr/lib64 symlink is added to the installer udeb that change is not a real problem. It is just my personal opinion that we should not unnecessarily make the amd64 port depend on that symlink. I think that libraries should be accessed through /usr/lib where they are installed. Without your patch the /usr/lib64 symlink could safely be removed without disturbing the system because libraries were accessed through /usr/lib. With your patch, the /usr/lib64 symlink can no longer be removed without problems because /usr/lib is not searched for libraries by the linker unless /usr/lib is explicitly added to /etc/ld.so.conf. 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. Yes, without the /lib64 symlink the system breaks in any case because the path to the linker /lib64/ld-linux-x86-64.so.2 - which is hardcoded by gcc into every binary - no longer exists without the /lib64 symlink. But I liked the fact that up to now this was the _only_ thing which really used the /lib64 symlink. I do not like the ugly (/usr)/lib64 directories at all and I think they should be dropped in the long term. Again, this point is just my personal opinion and not really technically important to make things work now. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
Hi ! On Mon, Feb 13, 2006 at 04:53:46PM +0100, Andreas Jochens wrote: diff -u glibc-2.3.6/debian/sysdeps/amd64.mk glibc-2.3.6/debian/sysdeps/amd64.mk --- glibc-2.3.6/debian/sysdeps/amd64.mk +++ glibc-2.3.6/debian/sysdeps/amd64.mk @@ -20,0 +21,7 @@ + +define libc_extra_install +mv debian/tmp-libc/lib64 debian/tmp-libc/lib +mv debian/tmp-libc/usr/lib64/* debian/tmp-libc/usr/lib +for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink $$link | sed -e s#64##g) $$link ; done please add a line +for so in $$(find debian/tmp-libc/usr/lib -maxdepth 1 -type f -name *.so) ; do perl -pi -e s#/lib64/#/lib/#g $$so ; done to make sure that 'libc.so' and 'libpthread.so' use '/lib' and not '/lib64' to access the libraries. Ok. Done. With this change, glibc 2.3.6 with your patch builds and works fine for me on amd64. I have just tested a build with your suggested change, and it works correctly. Please find attached the final version of the patch, against the latest SVN. 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]
Bug#325226: libc6: Wrong dynamic linker on amd64
I have just tested a build with your suggested change, and it works
correctly. Please find attached the final version of the patch, against
the latest SVN.
And the patch...
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Index: debian/patches/amd64-lib.diff
===
--- debian/patches/amd64-lib.diff (révision 1173)
+++ debian/patches/amd64-lib.diff (copie de travail)
@@ -1,50 +0,0 @@
-#! /bin/sh -e
-
-# All lines beginning with `# DP:' are a description of the patch.
-# DP: Description: Use /lib instead of /lib64 for the native amd64 port
-# DP: Dpatch author: Andreas Jochens [EMAIL PROTECTED]
-# DP: Patch author:
-# DP: Upstream status: Debian-Specific
-# DP: Status Details:
-# DP: Date: 2004-06-07 (updated 2005-10-13)
-
-# This patch is for amd64 only; on i386 we want the 64-bit libraries
-# in /lib64.
-[ $DEB_HOST_ARCH != amd64 ] exit 0
-
-if [ $# -ne 2 ]; then
-echo 2 `basename $0`: script expects -patch|-unpatch as argument
-exit 1
-fi
-case $1 in
--patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;;
--unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;;
-*)
-echo 2 `basename $0`: script expects -patch|-unpatch as argument
-exit 1
-esac
-exit 0
-
-# append the patch here and adjust the -p? flag in the patch calls.
glibc-2.3.2/sysdeps/unix/sysv/linux/configure~ 2004-06-05
14:03:22.118247000 +0200
-+++ glibc-2.3.2/sysdeps/unix/sysv/linux/configure 2004-06-05
11:43:35.667961319 +0200
-@@ -224,7 +224,7 @@
- /usr | /usr/)
- # 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
- case $machine in
-- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
-+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
- mips/mips64/n64/* )
- libc_cv_slibdir=/lib64
- if test $libdir = '${exec_prefix}/lib'; then
glibc-2.3.2/sysdeps/unix/sysv/linux/configure.in~ 2004-07-05
09:52:28.0 +0200
-+++ glibc-2.3.2/sysdeps/unix/sysv/linux/configure.in 2004-07-05
12:18:07.995664571 +0200
-@@ -157,7 +157,7 @@
- /usr | /usr/)
- # 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
- case $machine in
-- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
-+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
- mips/mips64/n64/* )
- libc_cv_slibdir=/lib64
- if test $libdir = '${exec_prefix}/lib'; then
Index: debian/patches/series.amd64
===
--- debian/patches/series.amd64 (révision 1173)
+++ debian/patches/series.amd64 (copie de travail)
@@ -1,2 +0,0 @@
-amd64-lib.diff -p1
-
Index: debian/sysdeps/amd64.mk
===
--- debian/sysdeps/amd64.mk (révision 1173)
+++ debian/sysdeps/amd64.mk (copie de travail)
@@ -18,3 +18,11 @@
ln -sf lib debian/$(curpass)/lib64
ln -sf lib debian/$(curpass)/usr/lib64
endef
+
+define libc_extra_install
+mv debian/tmp-libc/lib64 debian/tmp-libc/lib
+mv debian/tmp-libc/usr/lib64/* debian/tmp-libc/usr/lib
+for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink
$$link | sed -e s#64##g) $$link ; done
+for so in $$(find debian/tmp-libc/usr/lib -maxdepth 1 -type f -name *.so) ; do
perl -pi -e s#/lib64/#/lib/#g $$so ; done
+endef
+
Bug#325226: libc6: Wrong dynamic linker on amd64
On 06-Feb-13 00:54, Aurelien Jarno wrote: Please find attached my latest version of the patch for this bug. I am waiting for your comments. Hello, diff -u glibc-2.3.6/debian/sysdeps/amd64.mk glibc-2.3.6/debian/sysdeps/amd64.mk --- glibc-2.3.6/debian/sysdeps/amd64.mk +++ glibc-2.3.6/debian/sysdeps/amd64.mk @@ -20,0 +21,7 @@ + +define libc_extra_install +mv debian/tmp-libc/lib64 debian/tmp-libc/lib +mv debian/tmp-libc/usr/lib64/* debian/tmp-libc/usr/lib +for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink $$link | sed -e s#64##g) $$link ; done please add a line +for so in $$(find debian/tmp-libc/usr/lib -maxdepth 1 -type f -name *.so) ; do perl -pi -e s#/lib64/#/lib/#g $$so ; done to make sure that 'libc.so' and 'libpthread.so' use '/lib' and not '/lib64' to access the libraries. +endef + With this change, glibc 2.3.6 with your patch builds and works fine for me on amd64. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
Please find attached my latest version of the patch for this bug. I am
waiting for your comments.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
diff -u glibc-2.3.6/debian/sysdeps/amd64.mk glibc-2.3.6/debian/sysdeps/amd64.mk
--- glibc-2.3.6/debian/sysdeps/amd64.mk
+++ glibc-2.3.6/debian/sysdeps/amd64.mk
@@ -20,0 +21,7 @@
+
+define libc_extra_install
+mv debian/tmp-libc/lib64 debian/tmp-libc/lib
+mv debian/tmp-libc/usr/lib64/* debian/tmp-libc/usr/lib
+for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink
$$link | sed -e s#64##g) $$link ; done
+endef
+
--- glibc-2.3.6/debian/patches/series.amd64
+++ glibc-2.3.6.orig/debian/patches/series.amd64
@@ -1,2 +0,0 @@
-amd64-lib.diff -p1
-
--- glibc-2.3.6/debian/patches/amd64-lib.diff
+++ glibc-2.3.6.orig/debian/patches/amd64-lib.diff
@@ -1,50 +0,0 @@
-#! /bin/sh -e
-
-# All lines beginning with `# DP:' are a description of the patch.
-# DP: Description: Use /lib instead of /lib64 for the native amd64 port
-# DP: Dpatch author: Andreas Jochens [EMAIL PROTECTED]
-# DP: Patch author:
-# DP: Upstream status: Debian-Specific
-# DP: Status Details:
-# DP: Date: 2004-06-07 (updated 2005-10-13)
-
-# This patch is for amd64 only; on i386 we want the 64-bit libraries
-# in /lib64.
-[ $DEB_HOST_ARCH != amd64 ] exit 0
-
-if [ $# -ne 2 ]; then
-echo 2 `basename $0`: script expects -patch|-unpatch as argument
-exit 1
-fi
-case $1 in
--patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;;
--unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;;
-*)
-echo 2 `basename $0`: script expects -patch|-unpatch as argument
-exit 1
-esac
-exit 0
-
-# append the patch here and adjust the -p? flag in the patch calls.
glibc-2.3.2/sysdeps/unix/sysv/linux/configure~ 2004-06-05
14:03:22.118247000 +0200
-+++ glibc-2.3.2/sysdeps/unix/sysv/linux/configure 2004-06-05
11:43:35.667961319 +0200
-@@ -224,7 +224,7 @@
- /usr | /usr/)
- # 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
- case $machine in
-- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
-+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
- mips/mips64/n64/* )
- libc_cv_slibdir=/lib64
- if test $libdir = '${exec_prefix}/lib'; then
glibc-2.3.2/sysdeps/unix/sysv/linux/configure.in~ 2004-07-05
09:52:28.0 +0200
-+++ glibc-2.3.2/sysdeps/unix/sysv/linux/configure.in 2004-07-05
12:18:07.995664571 +0200
-@@ -157,7 +157,7 @@
- /usr | /usr/)
- # 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
- case $machine in
-- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
-+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
- mips/mips64/n64/* )
- libc_cv_slibdir=/lib64
- if test $libdir = '${exec_prefix}/lib'; then
Bug#325226: libc6: Wrong dynamic linker on amd64
On 06-Feb-10 12:02, Aurelien Jarno wrote:
Please find attached a patch to fix the problem using another way. It
reverts amd64-lib.dpatch, and build the library in /{usr,}/lib64. It
then moves it to /{usr,}/lib during the installation phase of the
package.
It looks cleaner to me in the sense it is not a patch to the patch.
Hello,
your solution looks indeed nicer that the patch to the patch to fix
the linker path.
However, there is one (probably not really important) thing
which I do not like:
The patch will cause a lot of symlinks which currently point from
'/usr/lib/lib*.so.*' to '/lib/lib*.so.*' to be changed to point
to '/lib64/lib*.so.*' instead, e.g.
lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so - /lib/librt.so.1
would become
lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so - /lib64/librt.so.1
Currently, the /lib64 directory symlink is used _only_ to provide the
correct linker path. Nothing else in the distribution references
the /lib64 directory, i.e. everything is (or at least should
be) installed in /lib and nothing depends on the /lib64 symlink
with the single exception of the linker path.
I think it would be good to keep it that way and to let the symlinks
point to '/lib/lib*.so.*' as they do now.
Do you perhaps know of a simple way to achive this within your approach?
Anyway, thank you for your patch!
Regards
Andreas Jochens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
On Fri, Feb 10, 2006 at 12:48:21PM +0100, Andreas Jochens wrote: your solution looks indeed nicer that the patch to the patch to fix the linker path. However, there is one (probably not really important) thing which I do not like: The patch will cause a lot of symlinks which currently point from '/usr/lib/lib*.so.*' to '/lib/lib*.so.*' to be changed to point to '/lib64/lib*.so.*' instead, e.g. lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so - /lib/librt.so.1 would become lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so - /lib64/librt.so.1 Oh, I haven't thought of that. I tested the resulting binary, but I haven't looked at the links. Currently, the /lib64 directory symlink is used _only_ to provide the correct linker path. Nothing else in the distribution references the /lib64 directory, i.e. everything is (or at least should be) installed in /lib and nothing depends on the /lib64 symlink with the single exception of the linker path. That let me ask about having /lib64 as the real directory, and /lib as a symlink. At least it would make the /lib64 directory compliant with the FHS. Do you know what kind of problem that could cause, other than a complex upgrade? I think it would be good to keep it that way and to let the symlinks point to '/lib/lib*.so.*' as they do now. Do you perhaps know of a simple way to achive this within your approach? I think that's possible, I'll try do find a solution. -- .''`. 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]
Bug#325226: libc6: Wrong dynamic linker on amd64
On Fri, Feb 10, 2006 at 01:06:22PM +0100, Aurelien Jarno wrote: I think it would be good to keep it that way and to let the symlinks point to '/lib/lib*.so.*' as they do now. Do you perhaps know of a simple way to achive this within your approach? I think that's possible, I'll try do find a solution. The solution: add the following line in amd64.mk in libc_extra_install: for link in $$(find debian/tmp-libc/usr/lib -type l) ; do ln -sf $$(readlink $$link | sed -e s/64//g) $$link ; done It may be a bit ugly, but I currently haven't found better. Note that there is the same problem in the patch I sent for the i386 libc on amd64. The same kind of fix applies there. -- .''`. 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]
Bug#325226: libc6: Wrong dynamic linker on amd64
On 06-Feb-10 13:06, Aurelien Jarno wrote: Currently, the /lib64 directory symlink is used _only_ to provide the correct linker path. Nothing else in the distribution references the /lib64 directory, i.e. everything is (or at least should be) installed in /lib and nothing depends on the /lib64 symlink with the single exception of the linker path. That let me ask about having /lib64 as the real directory, and /lib as a symlink. At least it would make the /lib64 directory compliant with the FHS. Do you know what kind of problem that could cause, other than a complex upgrade? This question has a technical and a political answer. From the technical point of view it should be possible to make /lib64 a real directory and /lib a symlink to /lib64. But this would not get us any closer to the current FHS because with /lib being a symlink to /lib64 we still could not put 32-bit libraries in /lib as the current FHS requires. A full FHS conforming setup where 64-bit libraries are in /lib64 and 32-bit libraries in /lib would be _very_ difficult to achieve. The Debian amd64 porting team tried this at the beginning, but it turned out that this would involve many (ugly) changes to quite a lot of packages. So this is almost certainly not an option for Debian. Moreover, I think that the FHS is at fault here. It is simply _wrong_ to change the established standard filesystem layout which places native libraries in (/usr)/lib and put them in some other directory like /lib64 instead. The FHS should be changed to allow the amd64 port to use the standard directories (/usr)/lib for its native libraries. I filed a corresponding request to the FHS mailing list a while ago but I did not get any answer yet. It would probably help if people who are more important than me would support this request. Currently, Redhat and Suse install the native amd64 libraries in /lib64 while Debian, Ubuntu and Gentoo install them in /lib where they belong. I do not see any reason why the FHS should prohibit the saner approach used by Debian, Ubuntu and Gentoo. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
Andreas Jochens a écrit : On 06-Feb-10 13:06, Aurelien Jarno wrote: That let me ask about having /lib64 as the real directory, and /lib as a symlink. At least it would make the /lib64 directory compliant with the FHS. Do you know what kind of problem that could cause, other than a complex upgrade? This question has a technical and a political answer. From the technical point of view it should be possible to make /lib64 a real directory and /lib a symlink to /lib64. But this would not get us any closer to the current FHS because with /lib being a symlink to /lib64 we still could not put 32-bit libraries in /lib as the current FHS requires. A full FHS conforming setup where 64-bit libraries are in /lib64 and 32-bit libraries in /lib would be _very_ difficult to achieve. The Debian amd64 porting team tried this at the beginning, but it turned out that this would involve many (ugly) changes to quite a lot of packages. So this is almost certainly not an option for Debian. Moreover, I think that the FHS is at fault here. It is simply _wrong_ to change the established standard filesystem layout which places native libraries in (/usr)/lib and put them in some other directory like /lib64 instead. Ok, I better see the problem now. Using this reasoning it will even be good to have a (/usr)/lib32 defined in the FHS, with (/usr)/lib32 being a link to (/usr)/lib on plain i386 systems. This is why I am trying to do with the patch for the i386 libc on amd64. The FHS should be changed to allow the amd64 port to use the standard directories (/usr)/lib for its native libraries. I filed a corresponding request to the FHS mailing list a while ago but I did not get any answer yet. It would probably help if people who are more important than me would support this request. Note that some of the misp people have tri-arch patch pending, where (/usr)/lib, (/usr)/lib32 and (/usr)/lib64 are containing different ABI (two of them beeing a 32-bit ABI). So they really need (/usr)/lib32. You may try to contact them, so they could do the same demand. There is some posts about that on debian-mips in November 2005 I could also try to send a mail if you want, it will probably be ignored, but who knows. Currently, Redhat and Suse install the native amd64 libraries in /lib64 while Debian, Ubuntu and Gentoo install them in /lib where they belong. Well if I am right, Redhat and Suse does not have a full 64-bit system, but a 32-bit system with a few 64-bit libraries. At least it was the case for Suse last time I have checked. It looks like the FHS is done for them. They could probably be compared with Debian i386, which also supports 64-bit libraries in the way recommended by the FHS. I do not see any reason why the FHS should prohibit the saner approach used by Debian, Ubuntu and Gentoo. Given what if I have said in the previous paragraph, it looks like there are two different problems (64-bit system with a few 32-bit libraries and a 32-bit system with a few 64-bit libraries), and the FHS only give a recommendation for one of them. 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]
Bug#325226: libc6: Wrong dynamic linker on amd64
On Fri, Feb 10, 2006 at 04:06:25PM +0100, Aurelien Jarno wrote: [snip] The FHS should be changed to allow the amd64 port to use the standard directories (/usr)/lib for its native libraries. I filed a corresponding request to the FHS mailing list a while ago but I did not get any answer yet. It would probably help if people who are more important than me would support this request. Note that some of the misp people have tri-arch patch pending, where (/usr)/lib, (/usr)/lib32 and (/usr)/lib64 are containing different ABI (two of them beeing a 32-bit ABI). So they really need (/usr)/lib32. You may try to contact them, so they could do the same demand. The three mips ABIs are o32 (fully 32bit), n32 (32bit address space, 64bit register width) and n64 (fully 64bit). n32 traditionally uses (/usr)/lib32. The general problem with this approach is that it doesn't scale beyond 2-3 ABIs, and requires a native ABI definition. The multi-arch approach tries to do better (but needs more work before it can provide a viable alternative). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64.
Hello,
On 05-Aug-28 09:02, GOTO Masanori wrote:
At Sat, 27 Aug 2005 00:07:17 +0200,
Kurt Roeckx wrote:
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
ldd /usr/bin/iconv
libc.so.6 = /lib/libc.so.6 (0x002a9566e000)
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
The attached patch fixes this problem, i.e. it causes glibc to use
the correct linker path '/lib64/ld-linux-x86-64.so.2' for '/lib/libc.so.6',
'/usr/bin/iconv' and the other libc binaries and libraries on amd64.
The patch could be added to the existing debian/patches/amd64-lib.dpatch.
Regards
Andreas Jochens
diff -urN ../glibc-2.3.5/Makeconfig glibc-2.3.5/Makeconfig
--- ../glibc-2.3.5/Makeconfig 2005-08-30 17:48:26.0 +
+++ glibc-2.3.5/Makeconfig 2005-08-30 18:38:37.0 +
@@ -436,9 +436,13 @@
$(common-objpfx)libc% $(+postinit),$^) \
$(link-extra-libs-bounded) $(link-libc-bounded) $(+postctor)
$(+postinit)
endif
+rtlddir=$(slibdir)
+ifneq ('',$(findstring $(slibdir)/$(config-machine)/,/lib/x86_64/
/lib/powerpc64/))
+ rtlddir=/lib64
+endif
ifndef config-LDFLAGS
ifeq (yesyes,$(build-shared)$(elf))
-config-LDFLAGS = -Wl,-dynamic-linker=$(slibdir)/$(rtld-installed-name)
+config-LDFLAGS = -Wl,-dynamic-linker=$(rtlddir)/$(rtld-installed-name)
endif
endif
ifndef link-libc
diff -urN ../glibc-2.3.5/dlfcn/Makefile glibc-2.3.5/dlfcn/Makefile
--- ../glibc-2.3.5/dlfcn/Makefile 2004-10-18 23:08:31.0 +
+++ glibc-2.3.5/dlfcn/Makefile 2005-08-30 18:38:37.0 +
@@ -65,7 +65,7 @@
include ../Rules
-LDFLAGS-dl.so = -Wl,-dynamic-linker,$(slibdir)/$(rtld-installed-name)
+LDFLAGS-dl.so = -Wl,-dynamic-linker,$(rtlddir)/$(rtld-installed-name)
test-modules = $(addprefix $(objpfx),$(addsuffix .so,$(modules-names)))
$(test-modules): $(objpfx)%.so: $(objpfx)%.os $(common-objpfx)shlib.lds
diff -urN ../glibc-2.3.5/elf/Makefile glibc-2.3.5/elf/Makefile
--- ../glibc-2.3.5/elf/Makefile 2005-08-30 17:48:26.0 +
+++ glibc-2.3.5/elf/Makefile2005-08-30 18:38:37.0 +
@@ -296,7 +296,7 @@
rm -f [EMAIL PROTECTED]
# interp.c exists just to get this string into the libraries.
-CFLAGS-interp.c = -D'RUNTIME_LINKER=$(slibdir)/$(rtld-installed-name)' \
+CFLAGS-interp.c = -D'RUNTIME_LINKER=$(rtlddir)/$(rtld-installed-name)' \
-DNOT_IN_libc=1
$(objpfx)interp.os: $(common-objpfx)config.make
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#325226: libc6: Wrong dynamic linker on amd64.
Processing commands for [EMAIL PROTECTED]: severity 325226 important Bug#325226: libc6: Wrong dynamic linker on amd64. Severity set to `important'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64.
severity 325226 important thanks At Sat, 27 Aug 2005 00:07:17 +0200, Kurt Roeckx wrote: It seems that on amd64, all binaries and libraries in the libc6 pacakge have a wrong dynamic linker in the binaries. ldd /lib/libc.so.6 /lib/ld-linux-x86-64.so.2 (0x002a95556000) ldd /usr/bin/iconv libc.so.6 = /lib/libc.so.6 (0x002a9566e000) /lib/ld-linux-x86-64.so.2 (0x002a95556000) ... The ABI says that it should be /lib64/ld-linux-x86-64.so.2, and every other binary and lib does have that, except for things in the libc6 package. Note that that we have a /lib64 - lib symlinks, and that everything should get installed in /lib, it's just that the path in the binaries itself is wrong. I don't think it's really important, but it's probably nice to have this fixed. If you're going to fix this, could you please provide a patch for this so I can test it before you upload it? This bug exists in both sarge (2.3.2.ds1-22) and sid (2.3.5-4). Actually this bug is serious and grave. However, considering this problem, I need to investigate this issue more. In addition, I plan to fix /lib64 - /lib things (I'll post about it). I'm sorry but I put glibc 2.3.5-5 without two patches from Andreas' ppc64 and the fix for your problem, because testing is dammed. I focus them in the next 2.3.5-6. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64.
Package: libc6 Version: 2.3.2.ds1-22 Hi, It seems that on amd64, all binaries and libraries in the libc6 pacakge have a wrong dynamic linker in the binaries. ldd /lib/libc.so.6 /lib/ld-linux-x86-64.so.2 (0x002a95556000) ldd /usr/bin/iconv libc.so.6 = /lib/libc.so.6 (0x002a9566e000) /lib/ld-linux-x86-64.so.2 (0x002a95556000) ... The ABI says that it should be /lib64/ld-linux-x86-64.so.2, and every other binary and lib does have that, except for things in the libc6 package. Note that that we have a /lib64 - lib symlinks, and that everything should get installed in /lib, it's just that the path in the binaries itself is wrong. I don't think it's really important, but it's probably nice to have this fixed. If you're going to fix this, could you please provide a patch for this so I can test it before you upload it? This bug exists in both sarge (2.3.2.ds1-22) and sid (2.3.5-4). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
