Created attachment 717255 [details] Ebuild for sys-devel/gcc-10.3.0-r1::musl Porting the ebuild for sys-devel/gcc-10.2.0-r5 to sys-devel/gcc-10.3.0-r1 in the musl overlay appears to be a very trivial task. I could not tell if there is any other "magic" that needs to happen to make gcc-10.3 available to musl. One of my MIPS systems is currently building this target, so I'll know mid-afternoon tomorrow if it works or not. Can we get an ebuild for 10.3.0-r1 added to the musl overlay? I've attached the one I am using if it helps any, but the conversion is fairly straightforward. Also, what's holding things back from just putting the musl logic into the main repo? toolchain.eclass has a fair bit of ublibc-ng logic scattered all over it. Given uclibc-ng support seems to be dead, just rip that out and replace it with musl logic?
Looks to have compiled without issue: # mips-unknown-linux-musl-gcc --version mips-unknown-linux-musl-gcc (Gentoo 10.3.0-r1 p2) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Was also able to recompile sys-libs/musl without issue and resulting libc runs fine. That passes my simple smoke test.
Anarchy has invited me, via IRC, to raise a PR on the github repository, to update this, or feel free to send a patch or you can raise a PR also. I'm happy to do this, and add credit if you like and/or don't have time/access as appropriate :).
10.3.0 has been pushed to overlay, we are only keeping stable gcc in overlay these days. I will push 11.0.x in next few days for testing.
(In reply to Jory A. Pratt from comment #3) > 10.3.0 has been pushed to overlay, we are only keeping stable gcc in overlay > these days. I will push 11.0.x in next few days for testing. Why only stable? Is this just for gcc, or other packages as well? mips is pure unstable, so there wouldn't be any harm in adding 10.3.0-r1 (fixes two upstream PR's, #100489 and #100102).
(In reply to Joshua Kinard from comment #4) > (In reply to Jory A. Pratt from comment #3) > > 10.3.0 has been pushed to overlay, we are only keeping stable gcc in overlay > > these days. I will push 11.0.x in next few days for testing. > > Why only stable? Is this just for gcc, or other packages as well? mips is > pure unstable, so there wouldn't be any harm in adding 10.3.0-r1 (fixes two > upstream PR's, #100489 and #100102). Hmm, this is a catch-22 if ever there was one! Afaict we only keep stable ebuilds in ::musl, as most architectures supported have a stable profile. If this isn't the case for mips, we're going to have to come up with A Better Plan™ .. but exactly how we manage that, I'll leave to the wider team to debate! I suppose a decent start would probably be to include @system packages with ~mips keywords? I'll have another look into some tooling which helps keep ::musl better in sync with ::gentoo as it's already a bit hairy keeping track of existing updates :/
(In reply to Michael 'veremitz' Everitt from comment #5) > (In reply to Joshua Kinard from comment #4) > > (In reply to Jory A. Pratt from comment #3) > > > 10.3.0 has been pushed to overlay, we are only keeping stable gcc in overlay > > > these days. I will push 11.0.x in next few days for testing. > > > > Why only stable? Is this just for gcc, or other packages as well? mips is > > pure unstable, so there wouldn't be any harm in adding 10.3.0-r1 (fixes two > > upstream PR's, #100489 and #100102). > > Hmm, this is a catch-22 if ever there was one! > > Afaict we only keep stable ebuilds in ::musl, as most architectures > supported have a stable profile. If this isn't the case for mips, we're > going to have to come up with A Better Plan™ .. but exactly how we manage > that, I'll leave to the wider team to debate! I suppose a decent start would > probably be to include @system packages with ~mips keywords? > > I'll have another look into some tooling which helps keep ::musl better in > sync with ::gentoo as it's already a bit hairy keeping track of existing > updates :/ I have a musl chroot running the o32 ABI (big-endian) which is a base for the netboot images I build after catalyst runs. Hoping to kickstart an n32 ABI chroot after the catalyst stuff is done. Switched to musl after my uclibc-ng chroots bit the dust (as in literally stopped working for no reason; must've been a kernel thing?). For the toolchain packages, why not just integrate those into ::gentoo? The uclibc-ng logic can be pulled out at the same time, since I think Anthony wants to focus solely on musl. It's a small overall blob and 2-3 patches. Have those been sent in to upstream gcc as well?
(In reply to Joshua Kinard from comment #6) > > I have a musl chroot running the o32 ABI (big-endian) which is a base for > the netboot images I build after catalyst runs. Hoping to kickstart an n32 > ABI chroot after the catalyst stuff is done. Switched to musl after my > uclibc-ng chroots bit the dust (as in literally stopped working for no > reason; must've been a kernel thing?). > > For the toolchain packages, why not just integrate those into ::gentoo? The > uclibc-ng logic can be pulled out at the same time, since I think Anthony > wants to focus solely on musl. It's a small overall blob and 2-3 patches. > Have those been sent in to upstream gcc as well? I think blueness simply gave up on uclibc[-ng] as many did, after upstream went unresponsive for a period. Afaik he's barely active in Gentoo as RL issues took over, exacerbated by coronavirus changes to his teaching commitments. I think toolchain has been reluctant to make the necessary changes to accomodate musl wholesale, although with sam's recent contributions, this may be worth revisiting. Afaik, although the likes of slyfox have submitted some changes to upstream gnu, because it's musl they're pretty lazy at incorporating any necessary changes. However, to our advantage, since various distributions have/are adopting musl, it's getting much greater exposure, and many upstreams are adapting their code to be more portable, so all is not lost here - it's just a matter of educating people that their code/build-system is written sub-optimally! :)
11.1.0-r1 is now in the overlay as well.
