Created attachment 511946 [details] sys-libs/musl-1.1.18-r1.ebuild A fairly simple bug; the ebuild does not respect EPREFIX, and as such will not merge in a prefix because it installs files to locations outside of the prefix (at least when using crossdev inside prefix itself; unsure about how a rap style musl prefix will work, but that's another project for another day) Attached is musl-1.1.18-r1.ebuild which fixes the issue (and still works with non-prefixed crossdev, will need testing as the main system's libc, however), and a patch to musl-9999.ebuild with the same fix included.
Created attachment 511948 [details, diff] sys-apps/musl-9999 patch
Alternatively, you can merge this pull request on our git mirror: https://github.com/gentoo/gentoo/pull/6678
The change looks good to me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fcf2e327095c1329a4044950cadfda036db8245 commit 0fcf2e327095c1329a4044950cadfda036db8245 Author: Marty E. Plummer <hanetzer@protonmail.com> AuthorDate: 2017-12-29 11:02:09 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2017-12-29 18:21:44 +0000 sys-libs/musl: prefixify build Currently building a musl libc toolchain inside of gentoo prefix with crossdev will fail, due to installing files outside of the prefix. Added ${EPREFIX} and ${ED} where apropriate fixed this issue. Tested in a prefix with toolchain x86_64-gentoo-linux-musl, and tested on bare gentoo with x86_64-gentoo-linux-musl. Acked-by: blueness Package-Manager: Portage-2.3.19, Repoman-2.3.6 Signed-off-by: Marty E. Plummer <hanetzer@protonmail.com> Closes: https://bugs.gentoo.org/642612 Closes: https://github.com/gentoo/gentoo/pull/6678 sys-libs/musl/musl-1.1.18-r1.ebuild | 118 ++++++++++++++++++++++++++++++++++++ sys-libs/musl/musl-9999.ebuild | 4 +- 2 files changed, 120 insertions(+), 2 deletions(-)
Was reverted as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8952fa97a5120a8d02b4e565e5a48d6f314e534 https://github.com/gentoo/gentoo/pull/6705
I'm very much interested into having a working arm cross compiler, so please ping me if you need cpu time on arm for testing this.
(In reply to tt_1 from comment #6) > I'm very much interested into having a working arm cross compiler, so please > ping me if you need cpu time on arm for testing this. I'm not in principle opposed to this. The first commit was innocent. The second commit (presented on github) was no where tested enough. Let me explain why I'm worried. Certain operations in certain environments must be atomic. Touching ldconfig in the way suggested may break during bootstrapping in a catalyst or GRS environment. I'm willing to test at my end, but not in a piecemeal fashion. Here's what I suggest: get an overlay read with *all* of the commits there. When you feel its ready, I'll submit it to testing in various build environments at my end. There is a further problem with this approach and that is that I plan to replace ldconfig (currenly a bash script) with a program written in C. At that point, your approach will break. You can cross that bridge when we get there.
(In reply to Anthony Basile from comment #7) > (In reply to tt_1 from comment #6) > > I'm very much interested into having a working arm cross compiler, so please > > ping me if you need cpu time on arm for testing this. > > I'm not in principle opposed to this. The first commit was innocent. The > second commit (presented on github) was no where tested enough. Let me > explain why I'm worried. Certain operations in certain environments must be > atomic. Touching ldconfig in the way suggested may break during > bootstrapping in a catalyst or GRS environment. I'm willing to test at my > end, but not in a piecemeal fashion. > > Here's what I suggest: get an overlay read with *all* of the commits there. > When you feel its ready, I'll submit it to testing in various build > environments at my end. > > There is a further problem with this approach and that is that I plan to > replace ldconfig (currenly a bash script) with a program written in C. At > that point, your approach will break. You can cross that bridge when we get > there. Well, I did do some testing on baremetal (musl based chroot) and via crossdev (glibc, main system) and prefix (glibc prefix on glibc root), plus work on a musl prefix on baremetal musl (prior musl chroot). Granted, I did not test catalyst, so that should be done. https://github.com/hanetzer/musl-prefix is the work I've done so far on it, but I really can't get the profiles to play nice from overlays.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a9b1dd3546c9849e5e342d246bdddea95c00dd2a commit a9b1dd3546c9849e5e342d246bdddea95c00dd2a Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-05-20 22:06:40 +0000 Commit: Jory Pratt <anarchy@gentoo.org> CommitDate: 2020-05-20 22:12:03 +0000 sys-libs/musl: extract $(ARCH)$(SUBARCH) from config.mak Closes: https://bugs.gentoo.org/642612 Closes: https://bugs.gentoo.org/645626 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by: Jory Pratt <anarchy@gentoo.org> sys-libs/musl/musl-1.1.24.ebuild | 6 +++++- sys-libs/musl/musl-1.2.0.ebuild | 6 +++++- sys-libs/musl/musl-9999.ebuild | 6 +++++- 3 files changed, 15 insertions(+), 3 deletions(-)
