Mike Frysinger posted on Sun, 11 Sep 2011 15:55:49 -0400 as excerpted: > all current multilib systems use the sub-profile > features/multilib/lib32/. > in there, we set SYMLINK_LIB=yes. this causes the 32bit libs to move > from their normal ABI location in "lib" to "lib32" and then symlink > "lib" to "lib64". this is the only currently supported setup, but can be > considered legacy.
As a long-time Gentoo/amd64 user... It's worth noting that Gentoo was quite out in front on the amd64 thing, and this present "legacy" setup was developed pretty much at the same time as the FHS spec that deals with the issue. At the time, lib could have gone either way, legacy 32-bit lib with lib64, or new 64-bit lib with lib32. The early amd64/Gentoo implementors apparently decided to follow ia64 and make lib64 the 64-bit location, but for transition reasons, made lib a symlink to it, with lib32 the 32-bit version. Then the standard went the other way (apparently they decided the 64-bit target needed ported anyway so making it lib64 wasn't a big deal, and many 32-bit libraries and packages, with binary-only packages a major consideraction, would then simply continue to work without any changes at all). For a couple years, Gentoo/amd64 actively planned to switch, with one of the first steps being implementation of portage's FEATURES=multilib-strict, to catch the "bad" packages so bugs could be filed and they could be fixed. I personally ran this feature for some years and reported several bugs based on it. But somehow, it never happened, and over time, as 64-bit became common and pretty much everything (at least everything freedomware) was ported and the existing setup worked better and better, the pressure to leave what was now working reasonably well, well enough alone, grew. Thus we arrive at the current situation. I had actually thought that Gentoo/amd64 at least had given up on finally turning off that symlink and making lib 32-bit, and decided to leave things as they were and let time continue to deprecate 32-bit until it's no longer an issue, but Vapier's post indicates otherwise. Still, it has been "in the future" since I switched to Gentoo/amd64 in 2004, and as I said, with the pressure for 32-bit gradually going away and the current situation established now for quite some time and working reasonably well, honestly, is it even worth the upset and bugs it'll cause, any more? Meanwhile, I personally switched to no-multilib a few years ago now, and turned off FEATURES=multilib-strict after filing one last bug on it soon thereafter, so I don't know the current state there, but last I used it, the feature wasn't often killing merges, indicating that problem pretty much sinks into the ordinary bug count background. Unfortunately, I and others have occasionally tried breaking the symlink and having separate lib and lib64 dirs, and even with FEATURES=multilib- strict guaranteeing I had no breakers of that nature on the system, it still proved to be a rather difficult config to try to run, because there's apparently a lot of packages installing scripts, etc, to one path, but then trying to call them by the other path. Actually, last I tried it, openrc was one of the problem packages so I couldn't even complete a normal boot! Unfortunately, automated tinderbox testing for that isn't as easy as it might at first appear, since some packages will legitimately install both arch-neutral content to lib, and multilib content to lib64. But not all those will be false-positives either, if they still install something to one but look for it in the other. (AFAIK this was the problem with some of the openrc shell scripts, arguably arch-neutral and called from lib, but all installed (at least now) to (subdirs of) lib64. But, last time I tried it was before the openrc stabilization push, IIRC, so it's quite possible things have changes since then.) > in the future, multilib profiles we'll be moving to SYMLINK_LIB=no and > using just features/multilib/. so there will be no "lib32" dir at all, > "lib" will be for 32bit libs (just like the matching 32bit arch), and > "lib64" will be for 64bit libs. > > as for no-multilib systems, "lib64" will be the same, and "lib" will be > symlinked to "lib64". this will be easier i think to share files > between multilib and non-multilib 64bit systems. Thanks for that update, Mike. That is likely to be the least problematic for no-multilib users, so I at least don't have to worry about it so much. =:^) -- 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
