| 1 |
i dont care what the FHS has to say on the topic, so i havent bothered |
| 2 |
looking. below is documentation on the current system, and where i plan on |
| 3 |
taking things in the future. |
| 4 |
|
| 5 |
note that this only applies to amd64, ppc64, sparc64, and s390x systems where |
| 6 |
people think in terms of "32bit" and "64bit" ABIs (even though our ABI system |
| 7 |
isn't restricted at all to just these two states). |
| 8 |
|
| 9 |
all current multilib systems use the sub-profile features/multilib/lib32/. in |
| 10 |
there, we set SYMLINK_LIB=yes. this causes the 32bit libs to move from their |
| 11 |
normal ABI location in "lib" to "lib32" and then symlink "lib" to "lib64". |
| 12 |
this is the only currently supported setup, but can be considered legacy. |
| 13 |
|
| 14 |
in the future, multilib profiles we'll be moving to SYMLINK_LIB=no and using |
| 15 |
just features/multilib/. so there will be no "lib32" dir at all, "lib" will |
| 16 |
be for 32bit libs (just like the matching 32bit arch), and "lib64" will be for |
| 17 |
64bit libs. |
| 18 |
|
| 19 |
as for no-multilib systems, "lib64" will be the same, and "lib" will be |
| 20 |
symlinked to "lib64". this will be easier i think to share files between |
| 21 |
multilib and non-multilib 64bit systems. |
| 22 |
-mike |
Archives