[lsb-discuss] Multi-lib standards

Dennis Gilmore dennis at ausil.us
Mon Nov 23 06:58:46 PST 2009


On Monday 23 November 2009 02:23:37 am Bruce Dubbs wrote:
> Denis Silakov wrote:
> > Bruce Dubbs wrote:
> >> The only reason to have both
> >> 32-bit and 64-bit applications on the same system is to support old,
> >> unmaintained software that can't be rebuilt as 64-bit executables or
> >> libraries.
> >
> > I would agree that moving to 'pure' 64bit systems is a nice thing.
> > However, though most programs can be successfully built in 64bit mode,
> > those few apps that currently support 32bit only can be rather important
> > for users.
> >
> > I am far from asserting that all such 'problematic' software is really
> > old and unsupported. First, it's not so easy to rebuild some programs
> > for 64bit - the first example that comes to my mind is wine (surely,
> > there is great progress there, but wine64 is really experimental at the
> > moment). Yes, this is quite a specific program, but very useful in some
> > cases (at least for me:)).
> 
> Thanks for responding.  I agree with your logic here, but my original
> point was to try to get ahead of the curve and inform developers that
> 32-bit only is discouraged on 64-bit hardware.  I'm not suggesting
> elimination of 32-bit support immediately, but instead trying to
> accelerate progress to a point where it is no longer needed.

It really depends on the architecture.  ppc64 sparc64 and most risc based 64 
bit arches the only thing you gain by running 64 bit software is access to 
greater than 4GiB of ram.  unlike x86_64 where you gain extra registers and 
functionality that is only available via 64 bit mode.  you actually lose by 
running a pure 64 bit system.  you end up with bigger binaries that take 
longer to load and use more memory.  that is why they generally run 64 bit 
kernels and 32 bit userland.

> > Second, there are some rather popular proprietary programs that are
> > available only as 32bit binaries - e.g. skype, gizmo or adobe reader.
> > Such programs are not moving towards 64bit support as fast as open
> > source ones.
> 
> Of course, but they are, in general, starting to support 64-bit Linux.
> The current version of 64-bit Adobe flash works pretty well and there is
> no problem with 64-bit Nvidia code.  With a little nudge, others will
> work towards 64-bit packages.
I 
> > So I'd say that at the current state of art 'pure' 64bit system can be a
> > little less functional than its 32bit analogue. Finally, providing 32bit
> > libs in addition to 64bit once is really easy and relatively cheap, so
> > why not to do this?
> 
> Because maintaining two sets of libraries where one will do is
> non-trivial and expensive.  At a minimum, all changes have to tested twice.
it is trivial and still needed.  people are still making 32 bit cpus in mass 
quantities today.  at least how Fedora builds its packages,  we use the 32 bit 
rpms for multilib on 64 bit arches. we build one set of 32 bit and one set of 
64 bit rpms.  I also tend to run my kvm virtual machines 32 bit even though 
the host is 64 bit.  all the early atom cpus were 32 bit  the amd geode is 32 
bit, via ships 32 bit x86 cpus.  other arches like arm are currently only 32 
bit.   You really can not make a general assumption on this based solely on 
x86/x86_64 

> > On the other hand, it can make sense to provide them as some optional
> > part of the system - for example, take a look at 64bit ArchLinux. By
> > default, it only provides 64 bit libraries (located in /lib and
> > /usr/lib, there are no *lib64 folders at all). You can install lib32*
> > packages for particular libraries (all such libs will go to
> > subdirectories inside /opt/lib32/), or even setup a 32bit chroot (maybe
> > not very convenient, but more reliable).

This method certainly involves much more work and maintenance than other 
methods of supporting two arches.

> >
> > But ArchLinux is an exception to the rule, the common practice is still
> > to have */lib for 32bit libs and */lib64 for 64bit ones. So probably
> > it's too early to deprecate lib64 in the FHS.
> 
> I'm not sure you are using the term deprecate in the same way I am.  To
> me it means that it is discouraged and at some indefinite point in the
> future it will be removed.  Using that definition, I see no reason not
> to declare a mixed 32-bit and 64-bit system as deprecated right now.

on non x86/x86_64 arches its desirable. I suggest that we don't do that.  If 
that statement is mad it should be made clear that its for particular arches 
only.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20091123/831cb18e/attachment.pgp 


More information about the lsb-discuss mailing list