ia32-libs

[Jerone Young]

On Mon, 2008-12-22 at 19:58 +0100, Kjeldgaard Morten wrote:
> On 22/12/2008, at 17.15, Jerone Young wrote:
> 
> > On Mon, 2008-12-22 at 09:32 +0100, Kjeldgaard Morten wrote:
> >> On 22/12/2008, at 04.44, Jerone Young wrote:
> >>
> >>> You can easily run & install 32bit apps on these distros because the
> >>> 32-bit libs are placed in /lib & /usr/lib .. while the 64bit libs  
> >>> are
> >>> placed in /lib64 & /usr/lib64. This allows their 64bit distros to  
> >>> have
> >>> easy 32bit comparability and easily install 32bit packages on top of
> >>> the
> >>> 64bit distro.
> >>
> >> ... and is the cause of the horrible, horrible breakages. One of the
> >> reasons we left the RHEL distro.
> >
> > Can you explain? I have yet to see any breakage using this method.  
> > This
> > appears to be a much better method as libraries are easily seperated  
> > and
> > installable over time.
> 
> First of all, /usr/lib64 and /lib64 are awful kludges. The _logical_  
> place to put  libraries  is /usr/lib and /lib, no matter what hardware  
> the system is running on. Why should the filesystem vary with CPU  
> architechture? 

Because the binary libaries need to be split into different directories.
The reason users have to create an entire chroot enviroment to a 32bit
app on Ubuntu/Debian 64-bit is because of this very thing. While other
distros you don't have to do this since there is a clear split on the
binary library directories.

> For some strange reason, FSSTD introduced that awful / 
> lib<qual> and /usr/lib<qual> convention for 64 bit support, with the  
> exception of IA64 which goes in /usr/lib.

So
maybe /lib_x86_64 , /lib_x86,/lib_PPC32, /lib_PPC64, /lib_IA64, /lib_IA32 would also be a better convention? Perhaps just having /lib is dated since was normally not the case of having different binary libraries till current times.

>  One can guess that this  
> ended up in the standard due to pressure from RedHat.

So at least on PowerPC 64 this structure makes a lot of since. The
reason is most userland tools are built 32-bit. But you still want some
binaries to be 64bit. But there are 32bit versions of the same library
you might want also. So you do need a clear split between the library
directories. The thing is since there isn't a drastic divergence between
PowerPC 32 & 64 (unlike x86 & x86-64) it's actually better to have
32-bit binaries in a lot of cases, since they take up less address space
and use less on CPU cache.

> 
> Adopting /usr/lib64 will mean that packages for amd64l needs to be  
> configured differently from every other platform... a packaging and  
> debugging nightmare.

Yes this is mainly because things may not have started off not in the
best way. It may be worth it to try and use a better convention and get
past this. Though it break comparability now, it would help for
compatibility in the future. Though this is something that everyone
would have to agree with clearly. I can see a lot of opposition ;-)

> 
> In practice, RPM packagers can't figure out to create packages that do  
> this consistently, which means that 64 bit libraries end up in /usr/ 
> lib and sometimes 32 bit stuff ends up in /usr/lib64. Often, only one  
> version or the other is available. This is especially a problem since  
> RHEL only includes a small subset of packages, so you are forced to  
> use 3rd party repos of quite varying quality.

Yeah, this seems to be the case with 3rd parties not doing things
correct. Though acutally if the package uses autoconf RPM will actually
use options "--prefix=/usr --libdir=${prefix}/lib64" if it is building
it for 64bit. So this really is a case where these 3rd parties need to
fix there stuff or be educated better on how to package there libaries.

> 
> In a few years, the deprecation of 32-bit binaries (and hence  
> libraries) will be completed, and so the problem and the 32-specific  
> applications will disappear.

I agree. For myself this has become the case. There are now 64bit
versions of all the apps I use (even .. gasp .. adobe flash plugin ).
Though it does appear for many closed & even some open source apps this
is not the case.

For users wanting to consolidate there work loads to an Ubuntu/Debian
64bit box (most for the increased addressable memory), they face a big
problem if they have an older 32-bit package that they can't migrate
over to 64bit (or even get repackaged). Also many users using a chroot
environment causes a lot of issues. 

I'm looking at this more from our friends in the open source community
have this capability and Ubuntu/Debian is the only distro that doesn't.
By separating things we allow for packages built for x86 to be
installable on 64-bit x86-64 Ubuntu.


> 
> Cheers,
> Morten
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20081222/7b1ab3d1/attachment.pgp