Created attachment 734005 [details] Build failure when binutils-2.36.1 tries to rebuild itself under MIPS musl libc I'm making this bug really for documentation and as a reminder to myself to close out once binutils-2.37 is unmasked for archs and I get it fully tested on all of my MIPS targets. Core issue is on a MIPS big-endian target under musl libc, it is possible to build sys-devel/binutils-2.36.1* without issue, PROVIDED the current binutils version is <2.36. When 2.36.1 tries to rebuild itself, it will fail with a large number of "relocation R_MIPS_26" errors. A quick test with building sys-devel/binutils-2.37 using binutils-2.35.2, then using that binutils-2.37 to rebuild itself succeeds, implying that whatever the issue was, was caught and fixed in 2.37. I'm not too inclined to try and find a backport back to 2.36.1 since 2.37 is out and we can just move directly to that version. There's a ton of build failures, so see the attached TXT file for the gory details. glibc-based MIPS big-endian userlands are unaffected.
have you seen this on any other arch with musl?
(In reply to tt_1 from comment #1) > have you seen this on any other arch with musl? Nope, I only test musl on MIPS architecture, primarily older SGI systems, which predate the newer MIPS32rX/MIPS64rx platforms.
If you can, please avoid truncating build logs (upload the full thing, but you can give a snippet in the comments/description) and provide emerge --info.
(In reply to Sam James from comment #3) > If you can, please avoid truncating build logs (upload the full thing, but > you can give a snippet in the comments/description) and provide emerge > --info. There is nothing else in the build log that would have added any value, trust me. If there was, I would have included it as well, or depending on how bad the failure was, the entire thing. Unfortunately for emerge --info, I already jettisoned that chroot. My bad there. In any event, I really only opened this bug to document the error in case anyone else stumbled across it. I suspect it's something in binutils-2.36 that got fixed in binutils-2.37 upstream. It looks like 2.37_p1 got unmasked today, so once I get some testing done over the weekend, I will probably close this bug.
(In reply to Joshua Kinard from comment #4) > (In reply to Sam James from comment #3) > > If you can, please avoid truncating build logs (upload the full thing, but > > you can give a snippet in the comments/description) and provide emerge > > --info. > > There is nothing else in the build log that would have added any value, > trust me. If there was, I would have included it as well, or depending on > how bad the failure was, the entire thing. You're not the maintainer of the package. You don't get to make that determination.
unable to confirm on armv7a-unknown-linux-musleabihf
(In reply to tt_1 from comment #6) > unable to confirm on armv7a-unknown-linux-musleabihf unable to confirm on aarch64-gentoo-linux-musl
