[lsb-discuss] Multi-lib standards

Bruce Dubbs bruce.dubbs at gmail.com
Mon Nov 23 00:23:37 PST 2009

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.

> 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.

> 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.

> 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).
> 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.

   -- Bruce

More information about the lsb-discuss mailing list