1 |
Mike Frysinger wrote: |
2 |
> if you read FHS you'll see that both implementations are allowed. Gentoo isnt |
3 |
> violating anything here. wrt LSB, who knows. there are a ton of things we |
4 |
> dont follow with LSB. |
5 |
|
6 |
Actually, at first, FHS says that any /lib<qual> would be allowed, but |
7 |
it then goes into specifics in Chapter 6, Operating System Specific |
8 |
Annex. Under the heading "/lib64 and /lib32 : 64/32-bit libraries |
9 |
(architecture dependent)", it says, "The 64-bit architectures PPC64, |
10 |
s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and |
11 |
32-bit (or 31-bit on s390) libraries in /lib." |
12 |
|
13 |
>> The problem was that Gentoo's early amd64 implementation predated this |
14 |
>> standardization, and we had chosen the other way. While we've defaulted |
15 |
>> to lib64 for 64-bit libs for years, it has never been considered anything |
16 |
>> but experimental to break the lib --> lib64 link. AFAIK stable |
17 |
>> baselayout still doesn't get its libdir usage consistent, putting files |
18 |
>> in one but actually calling them using the other path, and boot breaks in |
19 |
>> various frustrating ways if lib and lib64 are not the same directory. |
20 |
>> Openrc gets it better now, but I'm not sure it's all fixed either -- it |
21 |
>> certainly wasn't last time I tried breaking the link. |
22 |
> |
23 |
> your "AFAIK" isnt useful. there are no open bugs about either version and |
24 |
> people assume that it's doing the right thing. |
25 |
|
26 |
Personally, I do have a ~amd64 Gentoo chroot with LIBDIR_x86="lib". |
27 |
There is only one place that I've found that it is still broken, namely |
28 |
one line in toolchain.eclass (patch attached). I've been meaning to file |
29 |
a bug for quite a while now, but never got around to it. |
30 |
|
31 |
-- |
32 |
Jonathan |