1 |
On Tuesday 20 October 2009 12:25:15 Duncan wrote: |
2 |
> Thomas Sachau posted on Tue, 20 Oct 2009 17:29:25 +0200 as excerpted: |
3 |
> > Michael Haubenwallner schrieb: |
4 |
> >> Isn't the intention of multilib to have a new (64bit) system be |
5 |
> >> compatible with the corresponding old (32bit) system? |
6 |
> >> |
7 |
> >> Please comment, thank you! |
8 |
> >> /haubi/ |
9 |
> > |
10 |
> > If you have a 64bit system, the default should be 64bit, both for libs |
11 |
> > and for binaries. The additional multilib support allows to install and |
12 |
> > use additional 32bit libs and binaries. Since they are not the system |
13 |
> > dafault, they shouldnt be in some default place like lib, but instead a |
14 |
> > different, but clearly labeled dir like lib32. So the Gentoo way looks |
15 |
> > like the right way to me. |
16 |
> |
17 |
> Except... it isn't, at least not if Gentoo is at all concerned about |
18 |
> standards, especially when they'll make things far easier for it. |
19 |
> |
20 |
> What you just described was the logic applied with, for example, ia64, |
21 |
> which is true 64-bit (only) native. However (as I understand it), the |
22 |
> Linux FHS and LSB used somewhat different logic for x86_64. |
23 |
|
24 |
if you read FHS you'll see that both implementations are allowed. Gentoo isnt |
25 |
violating anything here. wrt LSB, who knows. there are a ton of things we |
26 |
dont follow with LSB. |
27 |
|
28 |
> See, x86_64 is hardware native dual-bitness, so both 32-bit and 64-bit |
29 |
> can be said to be true native hardware bitness (this is NOT the case with |
30 |
> ia64). |
31 |
|
32 |
you can word "true native hardware bitness" (i dont even know what that means) |
33 |
however you like. fact is, first ia64 gen had hardware support for x86. no |
34 |
software levels needed. we decided to not support ia64 multilib because (1) |
35 |
the hardware sucked so bad and (2) no one actually wanted it and (3) none of |
36 |
the mainline packages were/are doing it and (4) newer ia64 gens dropped |
37 |
support for it. |
38 |
|
39 |
> Apparently due to that and to the vast number of legacy 32-bit |
40 |
> apps around, many binary-only apps doing obscure and unpredictable things |
41 |
> that could well break if assumptions about lib proved invalid, they |
42 |
> decided to keep the 32-bit lib location just as it was, believing it |
43 |
> easier to create the new lib64 for 64-bit, then to worry about whatever |
44 |
> obscure and exotic stuff various binary-only apps might be doing. Since |
45 |
> this was just one more change to add to the list of changes already being |
46 |
> made to port apps to amd64, it was considered easier than the other way, |
47 |
> and thus became the standard. |
48 |
|
49 |
the only binary encoded 32bit /lib/ path is the ldso which is why we symlinked |
50 |
that too |
51 |
|
52 |
> The problem was that Gentoo's early amd64 implementation predated this |
53 |
> standardization, and we had chosen the other way. While we've defaulted |
54 |
> to lib64 for 64-bit libs for years, it has never been considered anything |
55 |
> but experimental to break the lib --> lib64 link. AFAIK stable |
56 |
> baselayout still doesn't get its libdir usage consistent, putting files |
57 |
> in one but actually calling them using the other path, and boot breaks in |
58 |
> various frustrating ways if lib and lib64 are not the same directory. |
59 |
> Openrc gets it better now, but I'm not sure it's all fixed either -- it |
60 |
> certainly wasn't last time I tried breaking the link. |
61 |
|
62 |
your "AFAIK" isnt useful. there are no open bugs about either version and |
63 |
people assume that it's doing the right thing. |
64 |
|
65 |
> So before Gentoo can switch to the FHS/LSB 32-bit lib on amd64 multilib, |
66 |
> it must first fix those last inconsistent usages, and make it possible to |
67 |
> break the lib --> lib64 link. Then in theory at least, after awhile with |
68 |
> no bugs, or at least no big ones related to this issue, it might be |
69 |
> considered safe to move 32-bit back to lib, where the LSB/FHS says it |
70 |
> should be. |
71 |
|
72 |
we've already switched to the FHS implementation |
73 |
-mike |