Re: 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
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-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 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-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
Re: 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
