Created attachment 342192 [details] cross-mips64el-unknown-linux-gnu-info.log See attached logs for more details Command that fails: crossdev -A n64 -t mips64el-unknown-linux-gnu
Created attachment 342194 [details] cross-mips64el-unknown-linux-gnu-glibc.log.xz
as discussed on irc, our cross ebuilds atm attempt to filter the LDFLAGS/etc... settings and then use the result. really what we want is for crossdev to set up TARGET_{C,LD,etc...}FLAGS like we do with TARGET_ABI atm.
Any further update on this bug? I found another problem related to using LTO on the host arch. Since to use LTO properly, you have to include CFLAGS in LDFLAGS, and since glibc erroneously tries using the host's LDFLAGS value, it's passing incorrect arguments to the stage2 cross-compiler. The problem is in glibc's configure script where it is using $ASFLAGS, $LDFLAGS, $CPPFLAGS, and $CFLAGS incorrectly for cross-builds, it looks. Manually running this command at the shell gets me an o32-only glibc cross-build: ASFLAGS="" LDFLAGS="-Wl,-z,now -Wl,-z,relro" CFLAGS="-O2 -pipe -march=mips4 -mtune=mips4 -fivopts -fforce-addr -fmodulo-sched" CPPFLAGS="-O2 -pipe -march=mips4 -mtune=mips4 -fivopts -fforce-addr -fmodulo-sched" Crossdev needs to override these before invoking the stage3 portion so that glibc doesn't suck up the wrong arch flags and pass them to the cross-toolchain. Otherwise, it's very difficult to sanely merge a stage3 or higher cross-toolchain.
I love rediscovering bugs. Especially when I was the last person to comment... So, what are the chances we get this fixed sometime soon?
probably want to update crossdev to: - query current CFLAGS/CPPFLAGS/CXXFLAGS/LDFLAGS - save those in the env .conf file as BUILD_xxx - reset the flags to basic defaults (e.g. CFLAGS='-O2') - allow the user to set the flags with the existing --genv/etc... flags then glibc should "just work" i think.
(In reply to SpanKY from comment #5) > probably want to update crossdev to: > - query current CFLAGS/CPPFLAGS/CXXFLAGS/LDFLAGS + ASFLAGS. > - save those in the env .conf file as BUILD_xxx > - reset the flags to basic defaults (e.g. CFLAGS='-O2') > - allow the user to set the flags with the existing --genv/etc... flags > > then glibc should "just work" i think. Sounds about right. Been a few months since I ran into this, so I forgot all about it until I rebuilt my mips64 toolchain for the newer binutils/glibc/gdb set. I wonder if this isn't something that should be bugged with glibc upstream, though, since I pointed out in my July 2014 comment that glibc's configure script is using the host LDFLAGS to pass to the cross-compiler?
Looks like glibc isn't the only affected libc. musl has similar problems that were fixed by overriding the various *FLAGS variables: >>> Configuring source in /ramfs/portage/cross-mips-unknown-linux-musl/musl-1.1.6/work/musl-1.1.6 ... mips-unknown-linux-musl-gcc checking for C compiler... mips-unknown-linux-musl-gcc checking whether C compiler works... no; compiler output follows: mips-unknown-linux-musl-gcc: error: unrecognized argument in option '-march=corei7' mips-unknown-linux-musl-gcc: note: valid arguments to '-march=' are: 10000 1004kc 1004kf 1004kf1_1 1004kf2_1 10k 12000 12k 14000 14k 16000 16k 2000 20kc 24kc 24kec 24kef 24kef1_1 24kef2_1 ... [snip] mips-unknown-linux-musl-gcc: error: unrecognized argument in option '-mtune=corei7' mips-unknown-linux-musl-gcc: note: valid arguments to '-mtune=' are: [snip] mips-unknown-linux-musl-gcc: error: unrecognized command line option '-mfpmath=sse' mips-unknown-linux-musl-gcc: error: unrecognized command line option '-msse' mips-unknown-linux-musl-gcc: error: unrecognized command line option '-msse2' mips-unknown-linux-musl-gcc: error: unrecognized command line option '-mssse3' mips-unknown-linux-musl-gcc: error: unrecognized command line option '-msse4.1' [snip] Additionally, musl somehow invoked the HOST strip tool instead of a cross- variant. Want a separate bug for that?
musl still sufers from this. How was this fixed for glibc? Maybe it's possible to expand the fix to musl?
Created attachment 565696 [details] crossdev script for multiple mips targets (In reply to tt_1 from comment #8) > musl still sufers from this. > > How was this fixed for glibc? Maybe it's possible to expand the fix to musl? Not sure if it was ever fixed. I resorted to crafting a shell script that manipulates the various export flags and it single-steps crossdev through all four stages. Script is attached. Just uncomment one kernel, binutils, gcc, and libc flavour/version of your liking. Check the portage tree beforehand to see what the latest versions are and update the script as needed. For updating an existing toolchain, I usually just wipe the existing toolchain out using 'crossdev -C <CHOST>', then use the script to re-install it. I haven't tried a musl toolchain in some time, however, so no promises that it builds. At the bottom of the script is a commented-out "stage2", which is used when stage3 or stage4 fails for unknown reasons. stage2 is the bare-minimum I need for rolling kernels for MIPS machines. So you can use that to see how far it gets or at least pin down the failure point. Might shed some light on things.
