1 |
> > 1) We stop caring about anything except rv64gc/lp64d. |
2 |
> > People can still bootstrap other stuff with crossdev etc, but the |
3 |
> > Gentoo tree and the riscv keyword reflect that things work with |
4 |
> > above -mabi and -march settings. |
5 |
> |
6 |
> fine by me, for current software/upstream state, it's probably the |
7 |
> most practical way to only support lp64d, this will significantly |
8 |
> ease our life .. besides, it's relatively easy if people want to |
9 |
> support more (lp64/lp32..) later |
10 |
> |
11 |
|
12 |
++ |
13 |
|
14 |
> > 2) We drop the multilib paths and use "normal" lib64, with |
15 |
> > additional "safety symlinks" (/usr)/lib64/lp64d -> . |
16 |
> > This is what SuSE and (I think) Fedora already does. The symlink |
17 |
> > should be there since "lib64" is NOT an official fallback coded |
18 |
> > into gcc/glibc/binutils; the only fallback present is "lib" ... |
19 |
> can we use different scheme for non-multilib vs multilib? |
20 |
> 1) non-multilibe: just use "normal" lib64, keep align with other |
21 |
> ARCHs (amd64)? |
22 |
|
23 |
++ |
24 |
|
25 |
> 2) multilib: just stick to current two level lib path |
26 |
|
27 |
We can try that but it doesn't solve any of our problems (and we'd |
28 |
have to keep carrying the two-level dir patches). |
29 |
|
30 |
(I've already decided some time ago that supporting real multilib |
31 |
stages is too much effort for insufficient gain and stopped publishing |
32 |
them. Until recently I still built them; since glibc-2.33 they broke |
33 |
and while I know how to fix things I haven't had time to do it yet.) |
34 |
|
35 |
So if we keep the multilib scheme around, then IMHO only as internal |
36 |
workaround until we/upstream/... have figured out a better directory |
37 |
scheme. |
38 |
|
39 |
|
40 |
|
41 |
-- |
42 |
Andreas K. Hüttel |
43 |
dilfridge@g.o |
44 |
Gentoo Linux developer |
45 |
(council, toolchain, base-system, perl, libreoffice) |