Add multi-lib capabilities

[bdubbs@…]

The current LFS can build a pure 64-bit version of Gnu/Linux. The next major version will add multi-lib capabilities.

[bdubbs@…]

How to implement multi-lib is a real problem. There are multiple ways to implement it. We need to have a discussion to determine how we are going to approach this ticket.

For reference, see the thread starting at:

​https://lists.linux-foundation.org/pipermail/lsb-discuss/2009-November/006216.html

and especially

​https://lists.linux-foundation.org/pipermail/lsb-discuss/2009-November/006227.html

[willimm]

Both CLFS Multilib and DIY are very good places to start:

​http://cross-lfs.org/view/svn/native64

​http://refbuild.diy-linux.org/

CLFS has a very highly developed multilib way, and DIY has one that can easily intergrate into our new build system. Why not combine ideas from both projects?

[bdubbs@…]

I don't think you understand the issue William. RedHat and SuSE do it one way and Debian & derivatives do it another. Both are valid. The issue is whether we choose one way or try to accommodate both, not the implementation method.

Unfortunately standards don't address the issue yet.

[willimm]

Replying to bdubbs@…:

I don't think you understand the issue William. RedHat and SuSE do it one way and Debian & derivatives do it another. Both are valid. The issue is whether we choose one way or try to accommodate both, not the implementation method.

Unfortunately standards don't address the issue yet.

I was talking about what would be good starting places to look at, not about this issue. I guess you didn't notice I was talking about good places to look at.

[bdubbs@…]

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.

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, there is very little value added in this ticket.

[willimm]

Replying to bdubbs@…:

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