Bruce Dubbs wrote: > 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.
Most of them can. But packages with a lot of inline assembly, like ffmpeg / mplayer, are *really* hard to make work unless the upstream maintainer has done it already (and mplayer is completely impossible if you need the binary win32 codecs, though that then falls under "proprietary" above). > 3. Even proprietary packages are making 64-bit versions available > (e.g. Nvidia, VMWare, and Adobe). True, but Wine is still a showstopper. If I can't play HL1, the system doesn't work. :-P > 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)? The published Linux ABIs (for 64-bit and 32-bit respectively) require /lib64/ld-linux-x86-64.so.2 and /lib/ld-linux.so.2, so Debian does it wrong. The one thing they do that I disagree with... (Well, they presumably have symlinks. But why mess around with symlinks manually, when you can just install the toolchain the way it was meant to be installed? :-) All it requires is a --libdir=/usr/lib64 on most other packages, which is a PITA to remember if you're doing it manually, but easy when you have per-package scripts with defaults.) > 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. It's still a straight line through the book, you just spend about twice as long in each section. But I do agree that it's more complicated. :-( > 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. Hmm. While what you say is true, neither CLFS nor DIY does a full UTF-8 (since neither uses man-db). Not their fault; they were branched off before Alexander cleaned much of that stuff up -- but it's still true. In order to get multilib+utf-8, you need to hack around all three of them. > For the costs in manpower and complexity, I see very little value > added in this ticket. ...And even after saying everything I've said above, I can't disagree with that.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
