Re: 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.
Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On 04-Oct-30 15:36, Bill Allombert wrote: On Mon, Oct 25, 2004 at 08:18:40AM +0200, Andreas Jochens wrote: 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. 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. 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. Regards Andreas Jochens 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?
Re: 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.
Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
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. 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 . Yes, of course. [...] 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. I fully agree with that. However, we do not have such a symlink yet. The pure64 archive has a patched 'base-files' package which creates such a symlink, but the maintainer of 'base-files' rejected that patch because he said it should be done by the 'glibc' package and I think his decision is correct. Logically it would belong in the 'libc6' package. It tried to put the symlink there, but this caused the system to stop working during updates of the 'libc6' package. We could easily have that symlink if we decided to make our binaries independent of the '/lib64' directory. Still, this particular patch is harmless in all these respects. The patch which really changes something is the patch to gcc which changes the name which is coded into every binary. Regards Andreas Jochens
