Re: Compatibility between Debian amd64 and other distributions
Hello Frans, Frans Pop wrote: Andreas Jochens wrote: The proposed glibc patch will break the installer. The installer does not have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. It has been decided following some discussion.) The symlink currently is there actually: rootskel (0.79) unstable; urgency=low [...] * Joshua Kwan - Symlink lib to lib64 to unhork amd64 images. Patch by Kurt Roeckx [EMAIL PROTECTED] (Closes: #256738) -- Colin Watson [EMAIL PROTECTED] Fri, 2 Jul 2004 12:05:29 +0100 The link is currently created for amd64 and ppc64. rootskel only creates the symlink from /lib64 to /lib which is required to run dynamically linked binaries. It does _not_ create the symlink from /usr/lib64 to /usr/lib. This can be verified by looking into an amd64 installer image. There is no /usr/lib64 in the amd64 installer images. BTW, thank you for applying the ppc64 patch. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Tuesday 26 September 2006 08:11, Andreas Jochens wrote: rootskel only creates the symlink from /lib64 to /lib which is required to run dynamically linked binaries. It does _not_ create the symlink from /usr/lib64 to /usr/lib. Sorry, my mistake. Missed the /usr/ bit :-( pgpZmrpeO4K3F.pgp Description: PGP signature
Re: Compatibility between Debian amd64 and other distributions
Hello, On 06-Sep-23 02:50, Goswin von Brederlow wrote: FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non Debian distributions follow that line. Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib. Steve Langasek had concerns about side-effects: That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. So far I have seen none. The proposed glibc patch will break the installer. The installer does not have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. It has been decided following some discussion.) The proposed patch changes the 64-bit library access paths used by glibc, i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the /usr/lib64 symlink would become a necessary requirement for things to work properly. Currently, the distribution works even without the /usr/lib64 symlink. Now I guess the release-team has to make a decision how important the FHS and compatibility is to Debian. The proposed patch may improve compatibility with Redhat or Novell but it does not improve compliance with the FHS. The relevant parts of the FHS 2.3 are: A) /lib : Essential shared libraries and kernel modules Purpose: The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin. B) /libqual : Alternate format essential shared libraries (optional) Purpose: There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. [Footnote:] This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them. C) /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. Rationale: This is a refinement of the general rules for /libqual and /usr/libqual. The architectures PPC64, s390x, sparc64 and AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. Summarized, Debian and Gentoo comply with A) and B) but not with C) while Redhat and Novell comply with B) and C) but not with A). It could be argued that the special rule C) overrides the general rule A). On the other hand, the Rationale of C) shows that C) was designed specifically for i386/amd64 biarch distributions with a strong i386 32-bit part. But Debian amd64 is a full native 64-bit distribution. The 32-bit part is purely optional and many people will not install any 32-bit binaries at all on their amd64 machines. The status quo for 64-bit and 32-bit libraries on Debian amd64 is as follows: 1) (/usr/)/lib64 is a symlink to (/usr)/lib 2) The dynamic linker name is /lib64/ld-linux-x86-64.so.2 (as per LSB). 3) 64-bit libraries are installed in /usr/lib and accessed via /usr/lib. 4) 32-bit libraries are installed in /emul/ia32-linux/(usr/)lib and there are symlinks from (/usr)/lib32 to /emul/ia32-linux(/usr)/lib. 1), 2) and 3) are consistent with the FHS 2.3 as long as no 32-bit libraries are installed on the system. Only 4) is a deviation from C) with respect to the location of the 32-bit libraries. The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in (/usr)/lib on amd64. To implement this in Debian would be difficult because almost every library package would have to be changed to install the native library files in a separate /usr/lib64 directory instead of the usual /usr/lib. The other Debian ports have their native libraries installed in /usr/lib. Many packages rely on this fact. Many things, especially during the build process, will break if the native libraries are not in /usr/lib. It would be a _lot_ of work to change the whole distribution to use /usr/lib64 instead of /usr/lib as the location of the native libraries. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Monday 25 September 2006 09:39, Andreas Jochens wrote: The proposed glibc patch will break the installer. The installer does not have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. It has been decided following some discussion.) The symlink currently is there actually: rootskel (0.79) unstable; urgency=low [...] * Joshua Kwan - Symlink lib to lib64 to unhork amd64 images. Patch by Kurt Roeckx [EMAIL PROTECTED] (Closes: #256738) -- Colin Watson [EMAIL PROTECTED] Fri, 2 Jul 2004 12:05:29 +0100 The link is currently created for amd64 and ppc64. pgpIyWlEAQKnp.pgp Description: PGP signature
Re: Compatibility between Debian amd64 and other distributions
Andreas Jochens [EMAIL PROTECTED] writes: Hello, On 06-Sep-23 02:50, Goswin von Brederlow wrote: FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non Debian distributions follow that line. Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib. Steve Langasek had concerns about side-effects: That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. So far I have seen none. The proposed glibc patch will break the installer. The installer does not have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. It has been decided following some discussion.) The proposed patch changes the 64-bit library access paths used by glibc, i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the /usr/lib64 symlink would become a necessary requirement for things to work properly. Currently, the distribution works even without the /usr/lib64 symlink. Ok, so we have to also set udeb_slibdir = /lib udeb_libdir = /usr/lib No biggy. Now I guess the release-team has to make a decision how important the FHS and compatibility is to Debian. The proposed patch may improve compatibility with Redhat or Novell but it does not improve compliance with the FHS. The relevant parts of the FHS 2.3 are: A) /lib : Essential shared libraries and kernel modules Purpose: The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin. B) /libqual : Alternate format essential shared libraries (optional) Purpose: There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. [Footnote:] This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them. C) /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. Rationale: This is a refinement of the general rules for /libqual and /usr/libqual. The architectures PPC64, s390x, sparc64 and AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. Summarized, Debian and Gentoo comply with A) and B) but not with C) while Redhat and Novell comply with B) and C) but not with A). I believe the installed Debian system conforms with A, B and C because lib and lib64 are the same for us. Debian (and gentoo) are unique in that. I don't think the FHS says anywhere that /lib64 must not be a link. B specifically allows for lib to be a link without invalidating A so the reverse should be the same. ... The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in (/usr)/lib on amd64. To implement this in Debian would be difficult because almost every library package would have to be changed to install the native library files in a separate /usr/lib64 directory instead of the usual /usr/lib. The other Debian ports have their native libraries installed in /usr/lib. Many packages rely on this fact. Many things, especially during the build process, will break if the native libraries are not in /usr/lib. Not really. Sources are a bit more resiliant than that. For one thing SuSe and RH have /usr/lib64 and it compiles there. What would break is the install process because the debian/rules or debian/*.install (the debhelper files) list /usr/lib. So It would be a _lot_ of work to change the whole distribution to use /usr/lib64 instead of /usr/lib as the location of the native libraries. nobody wants that. It was always said that changing things to (/usr)/lib64 will be difficult to transition and just wasted effort if it gets changed to (/usr)/lib/x86_64-linux-gnu as per multiarch proposal anyway. Regards Andreas Jochens MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 09:05:23PM -0400, Daniel Jacobowitz wrote: On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote: So what you seem to say is: If you copy the libc6 or static libraries between distributions you deserve to fail. Thats fine if you say it straight out. That's what I was trying to do! Does the same apply to libX11. Or can we do the compile for lib64, use lib trick there as it is not frozen? I don't think it matters, but it's up to the X maintainers. We'll probably end up following the same pattern as is decided for libc. I'd rather not diverge, especially if the solution used for libc is the correct one. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
Daniel Jacobowitz [EMAIL PROTECTED] writes: On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: But running Debian binaries on other distributions remains a problem. For example static binaries that use libnss* plugins will fail to find those plugins on other systems. Copying the debian libc6 to your ~/lib/ dir on another distribution will break locale plugins. Do you have any less contrived examples? FWIW, I think in either of these cases you deserve to keep both pieces. How do you keep both pieces if you are not root? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: But running Debian binaries on other distributions remains a problem. For example static binaries that use libnss* plugins will fail to find those plugins on other systems. Copying the debian libc6 to your ~/lib/ dir on another distribution will break locale plugins. Do you have any less contrived examples? FWIW, I think in either of these cases you deserve to keep both pieces. How do you keep both pieces if you are not root? That has nothing to do with it. Copying libc.so.6 to something other than its configured location breaks in plenty of other ways. Static binaries using nss are a long-standing and known source of problems, and if you copy them to any other version of glibc - configured differently or not - you're liable to crash. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
Daniel Jacobowitz [EMAIL PROTECTED] writes: On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: But running Debian binaries on other distributions remains a problem. For example static binaries that use libnss* plugins will fail to find those plugins on other systems. Copying the debian libc6 to your ~/lib/ dir on another distribution will break locale plugins. Do you have any less contrived examples? FWIW, I think in either of these cases you deserve to keep both pieces. How do you keep both pieces if you are not root? That has nothing to do with it. Copying libc.so.6 to something other than its configured location breaks in plenty of other ways. Static binaries using nss are a long-standing and known source of problems, and if you copy them to any other version of glibc - configured differently or not - you're liable to crash. So what you seem to say is: If you copy the libc6 or static libraries between distributions you deserve to fail. Thats fine if you say it straight out. Does the same apply to libX11. Or can we do the compile for lib64, use lib trick there as it is not frozen? As for after etch I hope binutils will add the multiarch patch and then we can finaly start moving stuff there as was planed for after sarge. MfG Goswin PS: Should the bug be retitled Note FHS exception/deviation for amd64 in release notes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote: So what you seem to say is: If you copy the libc6 or static libraries between distributions you deserve to fail. Thats fine if you say it straight out. That's what I was trying to do! Does the same apply to libX11. Or can we do the compile for lib64, use lib trick there as it is not frozen? I don't think it matters, but it's up to the X maintainers. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: But running Debian binaries on other distributions remains a problem. For example static binaries that use libnss* plugins will fail to find those plugins on other systems. Copying the debian libc6 to your ~/lib/ dir on another distribution will break locale plugins. Do you have any less contrived examples? FWIW, I think in either of these cases you deserve to keep both pieces. The fix is really simple. Compile glibc with libc_[s]libdir = [/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the compatibility links after the build. That results in libc6 using the FHS paths [/usr]/lib64 when looking for plugins, which means following the [/usr]/lib64 link on Debian, just like every other distributions glibc does on amd64. Nothing else changes. I'm perfectly happy to do this. After etch. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
