Add support for overriding the profile and install baselayout for merged-usr (rebase of #32)#45
Add support for overriding the profile and install baselayout for merged-usr (rebase of #32)#45mattst88 wants to merge 4 commits into
Conversation
Closes: https://bugs.gentoo.org/748975 Closes: gentoo#22 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
It's almost never what users want and causes issues even if they change the profile later. Closes: https://bugs.gentoo.org/748975 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
crossdev environments need to support merged-usr now, especially now that the profile can be selected. The logic around this is messy and best handled by the baselayout package when it is supported by the arch. This package now gets installed immediately before binutils. It means a few small extra files get installed, but that's a small price to pay. We could INSTALL_MASK them, but that would just add more complexity. Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
cc @chewi |
|
At the moment, I think this is more or less just a rebase of what I did. That might be enough if we ignore multilib. |
It is -- as stated in the title?
I think we should. |
What is the issue with multilib? I looked at #32 a while back and the notes just said there were problems with the ABI list on avr but didn't get into a whole lot of detail. Is there an easy way I can duplicate the issue? I ask because I am dealing with a bunch of the arm multi-lib stuff in a separate pr and I am not convinced we should just ignore it. |
|
Why "ignore multilib": most multilib cross-compilation is uncommon, there aren't many multilib profiles in Gentoo, and making the profile-ABI source-of-truth consistent with multilib.eclass across all arches is a rabbit hole. Single-ABI profiles (which is what the riscv CI targets use) work cleanly. For @kwhat's ARM multilib PR: you'd need to either (a) find/create an ARM multilib profile that produces correct dirs when baselayout is installed, or (b) handle ARM multilib dir creation separately like the old riscv code did. Option (b) reintroduces the complexity PR this PR is trying to eliminate. I'm unsure what problems Chewi had with RISC-V multilib, and he doesn't seem to remember either. I care (and this is why I have this PR) about building multilib MIPS toolchains, but they're currently failing to build for reasons unrelated to crossdev (AFAIU). I plan to investigate and solve that, but I think this PR is a good incremental step in the meantime. |
5 participants
No description provided.