| 1 |
Tres Melton posted <1127803486.6208.141.camel@×××××××××.org>, excerpted |
| 2 |
below, on Tue, 27 Sep 2005 00:44:46 -0600: |
| 3 |
|
| 4 |
> On Mon, 2005-09-26 at 22:22 -0400, Richard Freeman wrote: |
| 5 |
> |
| 6 |
>> Is it illegal to install 32-bit in /usr/lib? I thought that */lib/* was |
| 7 |
>> 32-bit, and */lib64/* was 64-bit. In any case, compliance wasn't my |
| 8 |
>> biggest goal since the whole thing is a kludge... |
| 9 |
> |
| 10 |
> That used to be the case. It is changing so that /usr/lib points to the |
| 11 |
> default bitness of the host. So /usr/lib has 64bit |
| 12 |
> libraries, /usr/lib64 is a pointer to /usr/lib and /usr/lib32 is where |
| 13 |
> the 32 bit stuff should go. |
| 14 |
|
| 15 |
Unless there was a Gentoo policy change I somehow missed, you have it |
| 16 |
reversed. Gentoo /used/ to have regular lib as the default 64-bit |
| 17 |
location, on amd64, matching ia64 (which doesn't do 32-bit in hardware so |
| 18 |
it only has one native hardware bitness, 64-bit, while amd64 is true dual |
| 19 |
bitness hardware). |
| 20 |
|
| 21 |
However, the LSB/FHS standardized on a 32-bit regular lib, and Gentoo |
| 22 |
amd64 has been slowly headed in that direction for about a year, now. So, |
| 23 |
unless they reversed course and I missed it... |
| 24 |
|
| 25 |
Currently, lib is still a symlink to lib64. However, there's the |
| 26 |
no-symlinks subprofile (entirely experimental and unsupported as of |
| 27 |
2005.0, I've been busy and haven't switched to the 2005.1 profile so don't |
| 28 |
know what the status is there), which would make lib64 the standard 64-bit |
| 29 |
location without the help of the lib -> lib64 symlink. lib32 remains the |
| 30 |
32-bit location, however, in all cases. |
| 31 |
|
| 32 |
Thus, with normal profiles, lib should be symlinked to lib64 (tho some |
| 33 |
apparently still have the symlink reversed, lib64 symlinking to lib, the |
| 34 |
old way), and 32-bit libs getting put there /could/ be problematic, if |
| 35 |
care isn't taken to keep them separate. (That's actually the biggest |
| 36 |
reason, AFAIK, that the LSB/FHS standard left lib as legacy 32-bit -- they |
| 37 |
decided most things would need a bit of effort to port to 64-bit anyway, |
| 38 |
so they might as well standardize on lib64 and do that as part of the |
| 39 |
porting, and leave unported legacy stuff to use lib, rather than having to |
| 40 |
mess with BOTH 32-bit and 64-bit stuff.) Of course, just how problematic |
| 41 |
it actually is depends on whether you have 64-bit and 32-bit libs both |
| 42 |
trying to install to the same name in /lib, or if your installation |
| 43 |
doesn't happen to have duplicate libs in both bitnesses. |
| 44 |
|
| 45 |
So... currently, due to Gentoo going one way originally while the standard |
| 46 |
ended up going the other, if you are using the normal Gentoo layout, it |
| 47 |
will indeed create issues putting 32-bit libs in lib. However, once the |
| 48 |
transfer is complete, some years down the road, or if your system is using |
| 49 |
LSB/FHS standards, 32-bit in lib will be fine, just as it was on x86. |
| 50 |
Again, that is... unless there was a policy reversal I somehow missed, and |
| 51 |
Gentoo is going back to 64-bit native lib. |
| 52 |
|
| 53 |
-- |
| 54 |
Duncan - List replies preferred. No HTML msgs. |
| 55 |
"Every nonfree program has a lord, a master -- |
| 56 |
and if you use the program, he is your master." Richard Stallman in |
| 57 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-amd64@g.o mailing list |
Archives