Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 594836

Summary: sys-devel/crossdev: uclibc-ng support
Product: Gentoo Linux Reporter: David Flogeras <dflogeras2>
Component: Current packagesAssignee: Gentoo Crossdev team <crossdev>
Status: RESOLVED FIXED    
Severity: enhancement CC: blueness, embedded, gentoo, herrtimson, jstein, slyfox, vapier, zseri.devel
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 570544, 627914    

Description David Flogeras 2016-09-22 21:28:52 UTC
Would be handy to create uclibc-ng toolchains for cross building

Reproducible: Always
Comment 1 David Flogeras 2017-02-28 20:05:01 UTC
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.
Comment 2 David Flogeras 2017-04-30 17:33:44 UTC
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.
Comment 3 Michael 'veremitz' Everitt 2018-09-22 18:36:10 UTC
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...
Comment 4 Michael 'veremitz' Everitt 2018-10-07 17:27:56 UTC
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.
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2018-12-02 13:00:38 UTC
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.
Comment 6 tt_1 2019-11-19 21:28:02 UTC
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.
Comment 7 Sergei Trofimovich (RETIRED) gentoo-dev 2019-12-22 23:59:26 UTC
Let's declare it done and sort out all the fallouts in individual packages.