| 1 |
On 22:01 Thu 06 May , Andreas K. Huettel wrote: |
| 2 |
> Howdy. |
| 3 |
> |
| 4 |
> I'm sending this not only to the team members on the alias, but also |
| 5 |
> to the whole dev list for discussion. |
| 6 |
> |
| 7 |
> So far I've been trying to support in Gentoo the full risc-v multilib |
| 8 |
> directory structure and the ABI sets supported by glibc. According to |
| 9 |
> specs this means for riscv64 |
| 10 |
> |
| 11 |
> -mabi=rv64gc -march=lp64d |
| 12 |
> libdir = lib64/lp64d |
| 13 |
> ("hardfloat") |
| 14 |
> |
| 15 |
> -mabi=rv64imac -march=lp64 |
| 16 |
> libdir = lib64/lp64 |
| 17 |
> ("softfloat") |
| 18 |
> |
| 19 |
> and theoretically similar for riscv32 (which just landed in glibc and |
| 20 |
> is still broken in qemu-user). |
| 21 |
> |
| 22 |
> However, this leads to several levels of pain (and I definitely dont |
| 23 |
> have time to deal with it myself): |
| 24 |
> |
| 25 |
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads |
| 26 |
> to difficulties in build systems. Right now Qt5 and CMake are still |
| 27 |
> somewhat broken (in *Gentoo*). |
| 28 |
> |
| 29 |
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should |
| 30 |
> have for decent Linux support.) |
| 31 |
> |
| 32 |
> I'm pretty sure these are not the only things, but they are somewhat |
| 33 |
> symptomatic. |
| 34 |
> |
| 35 |
> So, I would like to bring two proposals up for discussion. |
| 36 |
> |
| 37 |
> 1) We stop caring about anything except rv64gc/lp64d. |
| 38 |
> People can still bootstrap other stuff with crossdev etc, but the |
| 39 |
> Gentoo tree and the riscv keyword reflect that things work with above |
| 40 |
> -mabi and -march settings. |
| 41 |
> |
| 42 |
fine by me, for current software/upstream state, it's probably the most practical way |
| 43 |
to only support lp64d, this will significantly ease our life .. |
| 44 |
besides, it's relatively easy if people want to support more (lp64/lp32..) later |
| 45 |
|
| 46 |
> 2) We drop the multilib paths and use "normal" lib64, with additional |
| 47 |
> "safety symlinks" (/usr)/lib64/lp64d -> . |
| 48 |
> This is what SuSE and (I think) Fedora already does. The symlink |
| 49 |
> should be there since "lib64" is NOT an official fallback coded into |
| 50 |
> gcc/glibc/binutils; the only fallback present is "lib" ... |
| 51 |
> |
| 52 |
can we use different scheme for non-multilib vs multilib? |
| 53 |
1) non-multilibe: just use "normal" lib64, keep align with other ARCHs (amd64)? |
| 54 |
2) multilib: just stick to current two level lib path |
| 55 |
|
| 56 |
> -- |
| 57 |
> Andreas K. Hüttel |
| 58 |
> dilfridge@g.o |
| 59 |
> Gentoo Linux developer |
| 60 |
> (council, toolchain, base-system, perl, libreoffice) |
| 61 |
|
| 62 |
|
| 63 |
|
| 64 |
-- |
| 65 |
Yixun Lan (dlan) |
| 66 |
Gentoo Linux Developer |
| 67 |
GPG Key ID AABEFD55 |
Archives