Would be handy to create uclibc-ng toolchains for cross building Reproducible: Always
I thought I might sneakily upgrade my existing uclibc (plain, not -ng) cross toolchain to uclibc-ng. I upgraded cross uclibc -> uclibc-ng without issue (following the uclibc-ng upgrade guide with a grain of sale). However, I cannot recompile gcc against that (well I can if I only ask for a C compiler, with USE=""). It seems to first fail while configuring libgomp. I get a "C compiler cannot create executables" If I dig into the failed conftest, it fails with: /usr/libexec/gcc/armv6j-hardfloat-linux-uclibceabi/ld: cannot find crt1.o: No such file or directory /usr/libexec/gcc/armv6j-hardfloat-linux-uclibceabi/ld: cannot find crti.o: No such file or directory If I manually run the intermediate xgcc with the command line from config.log and add -v I see that collect2 is the culprit. If I compare the command line args that xgcc passes to collect2 with a working gcc, it seems to pass the whole path to crt1.o crti.o. On a working compiler, it has: ... -X -m armelf_linux_eabi /usr/armv6j-hardfloat-linux-uclibceabi/usr/lib/crt1.o /usr/armv6j-hardfloat-linux-uclibceabi/usr/lib/crti.o ... And on the broken xgcc during configure it is just: ... -X -m armelf_linux_eabi crt1.o crti.o ... Oddly, it does specify the complete path to crtn.o (and likewise not complain about it being MIA) If I manually add those paths to the collect2 invocation, xgcc can compile the conftest.c. I don't know where configure is going wrong or how to proceed. I have no idea if this is useful or not, but just figured I'd pop it here in case it helps.
I figured out what my problem was in Comment #1, the needed_libc=uclibc in toolchain.ecless needed to be "needed_libs=uclibc-ng", otherwise it resorts to trying to build a bare-metal compiler. Otherwise that part worked fine. That part will likely need to wait until blueness decides to officially replace uclibc with uclibc-ng. If I understand correctly, uclibc is undergoing a similar transformation as mingw32 -> w64. Sorry for the noise.
Stumbled upon this trying to build a cross-compiler to use with building uclibc[-ng] ARM stages (thanks slyfox). I can see an update to crossdev to change LPKG to 'uclibc-ng' partially works, but I will try the patch to toolchain.eclass to see if that helps me. For some reason, the problem I'm currently experiencing is that "uclibc-gcc" doesn't exist when its building uclibc-ng .. so there is definitely more to this problem than meets the eye...
I've had to modify the uclibc-ng ebuild to separate build-time package configuration from headers-only configuration. A fruitful discussion with slyfox on IRC suggested we adopt a comparable methodology to that used for the glibc ebuilds in splitting this out, and making appropriate adjustments for the host environment, as these should be irrelevant for headers install. I've opened a dialogue with uclibc-ng upstream as to a sensible way forward for this, and we'll see where this goes.
As uclibc was dropped from ::gentoo i flipped a few bits to target to uclibc-ng instead: - https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=c0c4e4355bf59cf04d35c6eb6e331b9118267113 - https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15e90a0bb563bac696449d794bb14b4b4f63c776 It's likely not enough but should be good first step.
As of today, I tried my luck with crossdev -S armv7a-unknown-linux-uclibceabihf --libc 1.0.32 --gcc 9.2.0-r2 and got a working cross compiler. one patch was needed for uclibc-ng, but it isn't the fault of crossdev. cross bootstraping from host with glibc propably not going to work anytime soon, as there's a conflict with glibc's libiconv and dev-libs/libiconv, but from a amd64-uclibc chroot it's no problem.
Let's declare it done and sort out all the fallouts in individual packages.
