Ticket #2491 Add multi-lib capabilities

Bruce Dubbs bruce.dubbs at gmail.com
Sun Jan 31 14:01:06 PST 2010


I am thinking about closing the subject ticket as WONTFIX.

There are a few reasons for this:

1.  The reason for multilib in the first place is to handle packages 
that are pre-compiled for a 32-bit only environment.  It only is needed 
on a 64-bit system.

2.  There are very few packages that actually need it.  Almost all of 
them proprietary.  Open source packages can be fixed to build in the 
native 'pure-64' environment.

3.  Even proprietary packages are making 64-bit versions available (e.g. 
Nvidia, VMWare, and Adobe).

4.  There are conflicting ways to implement multilib.  For example, is 
the paradigm /usr/lib and /usr/lib64 (like RedHat, Novell, and 
derivitives)?  Or is it /usr/lib and /usr/lib32 (like Debian and 
derivitives)?

5.  Building multilib consists of building packages multiple times 
making the instructions int the book quite a bit more verbose and 
complicated.  We already have a lot of problems with users just trying 
to build a single version of the packages.  Adding this complication 
goes against the philosophy of making the book relatively straight line.

Looking at a CentOS distribution, they have 1707 entries in /usr/lib64 
and 1281 in /usr/lib.  That doesn't count libraries in subdirectories. 
That's a lot of work for a few binary only packages.  For comparison, I 
have 1439 libraries in /usr/lib.

6.  If an advanced user wants to build a multilib system, they can use 
cross-lfs or diy-linux.  We already refer to cross-lfs in Section iii 
LFS Target Architectures.

For the costs in manpower and complexity, I see very little value added 
in this ticket.  The only thing then needed is to update the 5th 
paragraph in Section iii.

   -- Bruce



More information about the lfs-dev mailing list