Thomas Sachau posted on Tue, 20 Oct 2009 17:29:25 +0200 as excerpted: > Michael Haubenwallner schrieb: >> Isn't the intention of multilib to have a new (64bit) system be >> compatible with the corresponding old (32bit) system? >> >> Please comment, thank you! >> /haubi/ > > If you have a 64bit system, the default should be 64bit, both for libs > and for binaries. The additional multilib support allows to install and > use additional 32bit libs and binaries. Since they are not the system > dafault, they shouldnt be in some default place like lib, but instead a > different, but clearly labeled dir like lib32. So the Gentoo way looks > like the right way to me.
Except... it isn't, at least not if Gentoo is at all concerned about standards, especially when they'll make things far easier for it. What you just described was the logic applied with, for example, ia64, which is true 64-bit (only) native. However (as I understand it), the Linux FHS and LSB used somewhat different logic for x86_64. See, x86_64 is hardware native dual-bitness, so both 32-bit and 64-bit can be said to be true native hardware bitness (this is NOT the case with ia64). Apparently due to that and to the vast number of legacy 32-bit apps around, many binary-only apps doing obscure and unpredictable things that could well break if assumptions about lib proved invalid, they decided to keep the 32-bit lib location just as it was, believing it easier to create the new lib64 for 64-bit, then to worry about whatever obscure and exotic stuff various binary-only apps might be doing. Since this was just one more change to add to the list of changes already being made to port apps to amd64, it was considered easier than the other way, and thus became the standard. The problem was that Gentoo's early amd64 implementation predated this standardization, and we had chosen the other way. While we've defaulted to lib64 for 64-bit libs for years, it has never been considered anything but experimental to break the lib --> lib64 link. AFAIK stable baselayout still doesn't get its libdir usage consistent, putting files in one but actually calling them using the other path, and boot breaks in various frustrating ways if lib and lib64 are not the same directory. Openrc gets it better now, but I'm not sure it's all fixed either -- it certainly wasn't last time I tried breaking the link. So before Gentoo can switch to the FHS/LSB 32-bit lib on amd64 multilib, it must first fix those last inconsistent usages, and make it possible to break the lib --> lib64 link. Then in theory at least, after awhile with no bugs, or at least no big ones related to this issue, it might be considered safe to move 32-bit back to lib, where the LSB/FHS says it should be. > And better support for this part is my current multilib-portage project, > which allows compilation and installation of additional 32bit libs and > binaries. While I'm a no-multilib user here, I'm glad someone's finally getting that close enough to mainline merge to talk about it! There's a lot of folks for whom it will make life far easier. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
