Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Mon, Oct 25, 2004 at 08:18:40AM +0200, Andreas Jochens wrote: On 04-Oct-24 23:24, Kurt Roeckx wrote: On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote: This patch is harmless with respect to any LSB requirement. The name of the dynamic loader, which is coded into every binary can only be changed in the gcc package. This patch does not change that. I don't know what you all changed in the gcc-3.4 archive. But this is what I now get with something I just compiled: ldd test libc.so.6 = /lib/libc.so.6 (0x002a9566d000) /lib/ld-linux-x86-64.so.2 = /lib/ld-linux-x86-64.so.2 (0x002a95556000) While with the pure64 archive with either gcc-3.3 of 3.4 it's still pointing to /lib64/ld-linux-x86-64.so.2 I patched the gcc-3.4 package in the amd64/gcc-3.4 archive to get that result. For the patch I used please look at BTS #277852. I recompiled the complete amd64/gcc-3.4 archive with that patch and without the '/lib64' and '/usr/lib64' symlinks in place. I still have to reupload most of the recompiled packages to alioth but you should be able to debootstrap a new chroot from the amd64/gcc-3.4 archive and do a 'rm /lib64' without making the system unusable. Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Sat, Oct 30, 2004 at 04:12:01PM +0200, Andreas Jochens wrote: Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. The binaries will run on all distributions which have the interpreter accessible as /lib/ld-linux-x86-64.so.2. Gentoo, Ubuntu and of course pure64 install the interpreter as /lib/ld-linux-x86-64.so.2 today, so the binaries will run on these distributions without changes. On other distributions it may be necessary to execute ln -sf /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 to run the binaries until those distributions install that symlink themselves. You cannot do that if you are not root, while you can extract binaries out of Debian packages and run them. For simple stuff it works fine. Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Does the LSB compatibility package for RedHat or Suse provide such a symlink ? P.S.: Do you really want to install Debian binary packages on other (non-Debian related) distributions (e.g. RedHat, SuSe)? Have you already tried that and did it work? Yes it works fine for the simple stuff I am interested in (mathematical command-line driven programs). It is far less trouble than installing a proper build environment without root access. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On 04-Oct-30 16:55, Bill Allombert wrote: On Sat, Oct 30, 2004 at 04:12:01PM +0200, Andreas Jochens wrote: Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Does the LSB compatibility package for RedHat or Suse provide such a symlink ? The LSB compatibility packages for Debian, RedHat and Suse install a special symlink which is defined by the LSB as 'ld-lsb-x86-64.so.1' instead of 'ld-linux-x86-64.so.2'. The LSB specifies that conforming binaries have to use that symlink. Such binaries can be compiled by passing the switch -Wl,-dynamic-linker=/lib64/ld-lsb-x86-64.so.1 to the gcc compiler. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Sat, Oct 23, 2004 at 09:52:11PM +0200, Andreas Jochens wrote:
+--- ldconfig.h 2002-04-22 11:51:40.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldconfig.h2004-10-07
14:47:52.649686928 +
+@@ -20,7 +20,7 @@
+
+ #define SYSDEP_KNOWN_INTERPRETER_NAMES \
+ { /lib/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
+- { /lib64/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
++ { /lib/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
+ #define SYSDEP_KNOWN_LIBRARY_NAMES \
+ { libc.so.6, FLAG_ELF_LIBC6 }, \
+ { libm.so.6, FLAG_ELF_LIBC6 },
Atleast part of the patch looks totaly wrong to me. Please do
not change the location of the dynamic loader. This is LSB
requirement that it's placed in /lib64. We've argued over this
more than once.
+--- ldd-rewrite.sed 2002-04-09 08:39:14.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2004-10-20
12:56:17.929716960 +
+@@ -1,3 +1,3 @@
+ /LD_TRACE_LOADED_OBJECTS=1/a\
+ add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out
+-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \264\4\5\6_
++s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \2\4\5\6_
I have no idea what this does, but I think it's about the same as
the previous one.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
Kurt, thanks for looking at my bug report (and for looking through so many failed packages on pure64 during the last few days!). On 04-Oct-24 15:55, Kurt Roeckx wrote: Atleast part of the patch looks totaly wrong to me. Please do not change the location of the dynamic loader. This is LSB requirement that it's placed in /lib64. We've argued over this more than once. The patch does not change the location of the dynamic loader. The dynamic loader is currently installed in '/lib' by the 'glibc' package and the patch will not change that. The dynamic loader is currently also accessible via the '/lib64' symlink and the patch will also not change that. The patch just makes sure that glibc itself accesses the dynamic loader at the place where it installs it, namely in '/lib' and not in '/lib64'. This is a good thing, because it makes the access work independently of the '/lib64' symlink without loosing anything. This patch is harmless with respect to any LSB requirement. The name of the dynamic loader, which is coded into every binary can only be changed in the gcc package. This patch does not change that. Furthermore, there is no LSB requirement which requires the dynamic loader to be installed in '/lib64' or to be accessible as '/lib64/ld-linux-x86-64.so.2'. The LSB requires that the dynamic loader is accessible through '/lib64/ld-lsb-x86-64.so.2' (note the 'lsb' instead of 'linux' in the middle). This is being taken care of by the 'lsb' package which installs a symlink '/lib64/ld-lsb-x86-64.so.2' which points to '/lib/ld-linux-x86-64-so.2' (actually, the current version of the 'lsb' package still has a bug which lets the symlink point to '/lib/ld-linux.so.2' instead). The LSB does not specify anything else regarding the location of the dynamic loader besides that is must be accessible through '/lib64/ld-lsb-x86-64.so.2'. +--- ldd-rewrite.sed2002-04-09 08:39:14.0 + glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2004-10-20 12:56:17.929716960 + +@@ -1,3 +1,3 @@ + /LD_TRACE_LOADED_OBJECTS=1/a\ + add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out +-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[ ]*$_\1\2\4\6 \264\4\5\6_ ++s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[ ]*$_\1\2\4\6 \2\4\5\6_ I have no idea what this does, but I think it's about the same as the previous one. Yes, this is basically the same as the previous one and the same as the above applies. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote: This patch is harmless with respect to any LSB requirement. The name of the dynamic loader, which is coded into every binary can only be changed in the gcc package. This patch does not change that. I don't know what you all changed in the gcc-3.4 archive. But this is what I now get with something I just compiled: ldd test libc.so.6 = /lib/libc.so.6 (0x002a9566d000) /lib/ld-linux-x86-64.so.2 = /lib/ld-linux-x86-64.so.2 (0x002a95556000) While with the pure64 archive with either gcc-3.3 of 3.4 it's still pointing to /lib64/ld-linux-x86-64.so.2 Furthermore, there is no LSB requirement which requires the dynamic loader to be installed in '/lib64' or to be accessible as '/lib64/ld-linux-x86-64.so.2'. The LSB requires that the dynamic loader is accessible through '/lib64/ld-lsb-x86-64.so.2' (note the 'lsb' instead of 'linux' in the You seem to be right on that: | Program Interpreter/Dynamic Linker | | The LSB specifies the Program Interpreter to be /lib64/ld-lsb-x86-64.so.2. middle). This is being taken care of by the 'lsb' package which installs a symlink '/lib64/ld-lsb-x86-64.so.2' which points to '/lib/ld-linux-x86-64-so.2' (actually, the current ^ Should probably atleast be a . version of the 'lsb' package still has a bug which lets the symlink point to '/lib/ld-linux.so.2' instead). I just notices that same bug too. The LSB does not specify anything else regarding the location of the dynamic loader besides that is must be accessible through '/lib64/ld-lsb-x86-64.so.2'. Well, it seems that atleast it doesn't change anything with compliance to the LSB. But I still think it's wrong. Either glibc or gcc, whichever places that hardcoded path, should point to either /lib64/ld-lsb-x86-64.so.2 or /lib64/ld-linux-x86-64.so.2. And since the LSB says it should be /lib64/ld-lsb-x86-64.so.2 I would even say it should be changed to that. Anything else is going to cause problems running our binaries on an other distribution. We should also make sure that programs build on an other distro can be run on debian so I think we also need to have a /lib64/ld-linux-x86-64.so.2 provided in some way. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
Package: glibc
Severity: wishlist
Tags: patch
The attached patch changes the remaining two instances of 'lib64' to 'lib'
on amd64 by patching the files 'sysdeps/unix/sysv/linux/x86_64/ldconfig.h'
and 'sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed'.
The two patches are appended to the 'debian/patches/amd64-lib.dpatch' file
which already contains the change of the libdir directory from 'lib64' to
'lib' on amd64.
Regards
Andreas Jochens
diff -urN ../tmp-orig/glibc-2.3.2.ds1/debian/patches/amd64-lib.dpatch
./debian/patches/amd64-lib.dpatch
--- ../tmp-orig/glibc-2.3.2.ds1/debian/patches/amd64-lib.dpatch 2004-10-23
19:31:41.841744664 +
+++ ./debian/patches/amd64-lib.dpatch 2004-10-20 12:56:58.0 +
@@ -6,7 +6,7 @@
# DP: Patch author:
# DP: Upstream status: Debian-Specific
# DP: Status Details:
-# DP: Date: 2004-06-07
+# DP: Date: 2004-10-20
if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
@@ -44,3 +44,22 @@
mips/mips64/n64/* )
libc_cv_slibdir=/lib64
if test $libdir = '${exec_prefix}/lib'; then
+--- ldconfig.h 2002-04-22 11:51:40.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldconfig.h 2004-10-07
14:47:52.649686928 +
+@@ -20,7 +20,7 @@
+
+ #define SYSDEP_KNOWN_INTERPRETER_NAMES \
+ { /lib/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
+- { /lib64/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
++ { /lib/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
+ #define SYSDEP_KNOWN_LIBRARY_NAMES \
+ { libc.so.6, FLAG_ELF_LIBC6 },\
+ { libm.so.6, FLAG_ELF_LIBC6 },
+
+--- ldd-rewrite.sed2002-04-09 08:39:14.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2004-10-20
12:56:17.929716960 +
+@@ -1,3 +1,3 @@
+ /LD_TRACE_LOADED_OBJECTS=1/a\
+ add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out
+-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \264\4\5\6_
++s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \2\4\5\6_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
