Created attachment 824697 [details] build.log While trying to compile a cross toolchain with musl on MIPS I have noticed Musl puts it libraries in /usr/lib but GCC only looks for them in /lib. Creating a symlink of /lib to /usr/lib allows the second stage to build but a better solution is required. Steps to reproduce: 1. emerge crossdev 2. crossdev -s4 mips64-unknown-linux-musl 3. wait for failure when it reaches the gcc stage 2 phase This only seems to affect mip32, mip32el, mips64 and mips64el as every other mips tuple using Musl seems fine (I may have missed one in testing though.) I came across https://bugs.gentoo.org/652724 which shows a similar issue for glibc in the past but using the keepdir solution didn't seem to work for me but I will keep trying to see if some tweaking will fix it.
It's worth trying again. My stage3 armv7a-unknown-linux-musleabihf toolchain from earlier this month wouldn't even build hello.c because of crti.o. I rebuilt it from scratch to stage4 and now it's fine.
Created attachment 845648 [details] mips64-unknown-linux-musl I've just tested with a clean mips64-unknown-linux-musl crossdev build and I still getting the same issue with MIPS.
Confirmed on my end about the error w/ CHOST mips64-unknown-linux-musl. I wonder if this is an artifact of the whole merged-usr thing where some bit got overlooked or we have an unaccounted-for corner case?
I'm pretty confident this predates the commits for merge-usr but it is strange how it only happens on certain tuples for MIPS.
Update as of 2023-01-25 mips-unknown-linux-musl is now building successfully in crossdev, I'll test each toolchain over the next month or so to see if issues still occur elsewhere before closing this however this looks very promising from early tests.
So I've done further tests and mips64-unknown-linux-musl and mips32-unknown-linux-musl are still failing but I can't see any hint to why mips-unknown-linux-musl has started working again (unless it was failing for an unrelated issue and I've grouped it in with this issue).
FWIW I tried various gcc versions, various kernel header versions, and various binutils versions (and the oldest musl in tree, 1.2.3), and could not find a working combination.
(In reply to Andreas K. Hüttel from comment #7) > FWIW I tried various gcc versions, various kernel header versions, and > various binutils versions (and the oldest musl in tree, 1.2.3), and could > not find a working combination. The problem is deeper than crossdev. I managed to manually piece together a working mips64 musl system. However, gcc was unable to rebuild itself natively on it (while correctly building everything else). Other possible sources of the problem could be binutils or glibc.
I tested glibc on a mipsel32 system and didn't run into this issue last year which seemed likely due to the fix in https://bugs.gentoo.org/652724 I'll try setting up a few different builds to find where I hit the issue unless I've just misunderstood your own findings.
(In reply to immolo from comment #9) > I tested glibc on a mipsel32 system and didn't run into this issue last year > which seemed likely due to the fix in https://bugs.gentoo.org/652724 > > I'll try setting up a few different builds to find where I hit the issue > unless I've just misunderstood your own findings. OK please reopen if it still happens.
