#2491: Add multi-lib capabilities
-----------------------------------------+----------------------------------
Reporter: bdu...@… | Owner: lfs-b...@…
Type: task | Status: closed
Priority: normal | Milestone: 7.0
Component: Book | Version: SVN
Severity: normal | Resolution: wontfix
Keywords: |
-----------------------------------------+----------------------------------
Comment(by willimm):
Replying to [comment:6 bdu...@…]:
> Closing as WONTFIX
>
> 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.
Yes, but see my reply for 2.
> 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.
Well, some free software packages need 32-bit libaries, like ZSNES, but
yea, most of the apps that need multilib are proirtary, and being a FSF
member, I avoid propitary packages.
> 3. Even proprietary packages are making 64-bit versions available (e.g.
Nvidia, VMWare, and Adobe).
Yes, but rember that I don't use propitary apps...
> 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)?
From what I understand, /usr/lib for 32-bit libaries and /usr/lib64 for 64
bit versions is the correct way to implement multilib. See on 64 bit
systems, LD goes into /lib64, for one.
> 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.
Yes, this does make LFS more complex, and it also means increased build
time too.
> 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.
And also the CentOS issue.
> 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, there is very little value
added in this ticket.
Unless you want to run ZSNES on a 64-bit system, among other packages.
Other than that, I don't see any reason to do multilib.
PS: ZSNES, which I mentioned being 32-bit only, is located here:
zsnes.sourceforge.net
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2491#comment:7>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
