Summary: | gen_usr_ldscript: make a no-op for non native ABIs ? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexis Ballier <aballier> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=487696 https://bugs.gentoo.org/show_bug.cgi?id=417451 https://bugs.gentoo.org/show_bug.cgi?id=665704 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexis Ballier
![]() I was actually thinking something similar as well since I've been making the calls conditional as well. I'm thinking that if the council decides we do not support separat /usr without an initramfs or an early boot mechanism like busybox[sep-usr], we can make it a complete no-op on Linux in the future. Thoughts? William (In reply to William Hubbs from comment #2) > I'm thinking that if the council decides we do not support > separat /usr without an initramfs or an early boot mechanism like > busybox[sep-usr], we can make it a complete no-op on Linux in the > future. > > Thoughts? > > William As you wish, as I already said, I prefer doing it in a way giving choice to users, but its not something I would yell against: There was some effort to support sep usr like with eudev or mdev and making it unconditional would basically kill those efforts (not sure if those solutions are still working anyway). what you suggest is basically bug #417451 (this bug is more or less a duplicate of it too but I wanted a decision to know how to proceed with multilib ebuilds) i think getting it out of the way now for non-native ABIs makes sense. it's orthogonal to the /usr merge and applies to all systems, not just Linux. i've implemented this here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=838c3028555eb9d8f12017dcf43f0c7b0c8af90f it's contingent upon the ebuild using multilib-minimal eclasses, but that doesn't seem like a big deal as every multilib-enabled ebuild at this point is doing just that. |