It appears the latest crossdev forces the building of glibc headers because gcc-4.3 relies on them more. However, for mips, it appears that either crossdev or glibc itself is passing the wrong args to the HOSTCC, causing the configure script to fail: configure:3297: checking for suffix of object files configure:3323: gcc -c -O1 -pipe -mabi=n32 conftest.c >&5 cc1: error: unrecognized command line option "-mabi=n32" configure:3326: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "GNU C Library" | #define PACKAGE_TARNAME "c-library" | #define PACKAGE_VERSION "(see version.h)" | #define PACKAGE_STRING "GNU C Library (see version.h)" | #define PACKAGE_BUGREPORT "glibc" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3341: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. -mabi=n32 only works when sent to a mips toolchain. I suspect this is glibc's fault, but crossdev probably needs to account for it and somehow strip that parameter off.
(In reply to comment #0) > -mabi=n32 only works when sent to a mips toolchain. That is correct. You need to build a cross-gcc before you can build cross-glibc or cross-glibc-headers. Take a look here for a workaround : http://forums.gentoo.org/viewtopic-t-699683.html
Test comment to see if there's a bugzie issue around.
(In reply to comment #1) >> -mabi=n32 only works when sent to a mips toolchain. > > That is correct. You need to build a cross-gcc before you can build > cross-glibc or cross-glibc-headers. > > Take a look here for a workaround : > http://forums.gentoo.org/viewtopic-t-699683.html I should have stated this is a stage1 compiler, so it's C-Only and for kernel cross-compiles, so I didn't even have the cross-gcc built yet. Only binutils. Using emerge outside of crossdev got gcc to build fine without headers, so we just have to skip that step on mips it looks. Crossdev's code looks like it supports skipping headers based on arch, but I'll have to look at it more closely and see if that's possible or not.
crossdev doesnt set any env var
Is there a mechanism in crossdev that lets us bypass the glibc-headers stage? I managed to kludge crossdev through a build, and it popped out a working kernel toolchain, so I think for mips, we can just bypass this step.
(In reply to comment #9) > Is there a mechanism in crossdev that lets us bypass the glibc-headers stage? Yes, it is called --without-headers ps. It would save a bunch of people a little bit of typing if --without-headers was the default for crossdev.
and then you'd turn around and break everyone who attempted to use gcc-4.3. i dont think so.
crossdev + gcc-4.3 is broken anyway due to circular dependencies, and the default crossdev --with-headers always fails if you don't already have a crosscompiler installed for that target. amd64-multilib host --> x86 target is a special case that does not fail when you use --with-headers because the multilib toolchain already provides a crosscompiler (which makes crossdev redundant, in theory). ps. I still find crossdev very useful. I just use --without-headers and a 2 pass approach in order to get around the problems with gcc-4.3
this bug is about mips only ... do not spam completely unrelated topics
I just verified a few minutes ago that crossdev + gcc-4.3.2 + mips target fails on the libc-headers part with the exact same error as the original poster.
Please compare with Bug #246339 which demonstrates a similar problem building for a sparc target on an amd64 host (here, the compiler is gcc-4.1.2).
*** Bug 230505 has been marked as a duplicate of this bug. ***
http://sources.redhat.com/cgi-bin/cvsweb.cgi/ports/sysdeps/mips/preconfigure?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc&only_with_tag=HEAD Just found the cause is CPPFLAGS contains -mabi=n32. I really don't understand why CPPFLAGS should be like this. Maybe this would be a workaround: sed -i 's/-mabi=$mips_config_abi//g' ports/sysdeps/mips/preconfigure I haven't tested it though. I will test it and report the result
just modify this file ports/sysdeps/mips/preconfigure is not enough. There are some other problems. I will try to fix it ASAP and write a summary about it.
*** Bug 294347 has been marked as a duplicate of this bug. ***
I find a solution here http://www.lingcc.com/2010/01/06/10594/ The detail is edit the src_compile.eblit in /usr/portage/sys-libs/glibc/ . And You can find more in gentoo loongson overlay,the modification below was based on the overlay's ebuild. I have tested it，It works fine for me. files/eblits/src_compile.eblit 160a161,167 + if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then + # remove "-32" gcc switch, since gcc for other arch don't have this + sed -i '2 s/-mabi=32//g' "${S}"/ports/sysdeps/mips/mips32/Makefile + # fix stdio_lim.h missing problem + sed -i 's/_MIPS_SZPTR/32/' "${S}"/ports/sysdeps/mips/bits/wordsize.h + + fi files/eblits/src_install.eblit 203a204,207 + if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then + sed -i 's/\(__WORDSIZE.\+\)\(32\|64\)$/\1_MIPS_SZPTR/' \ + "${D}"/$(alt_headers)/bits/wordsize.h || die "restore wordsize.h failed" + fi
(In reply to comment #17) > I find a solution here http://www.lingcc.com/2010/01/06/10594/ > The detail is edit the src_compile.eblit in /usr/portage/sys-libs/glibc/ . And > You can find more in gentoo loongson overlay,the modification below was based > on the overlay's ebuild. I have tested it，It works fine for me. > > files/eblits/src_compile.eblit > 160a161,167 > + if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then > + # remove "-32" gcc switch, since gcc for other arch don't have this > + sed -i '2 s/-mabi=32//g' "${S}"/ports/sysdeps/mips/mips32/Makefile > + # fix stdio_lim.h missing problem > + sed -i 's/_MIPS_SZPTR/32/' "${S}"/ports/sysdeps/mips/bits/wordsize.h > + > + fi > files/eblits/src_install.eblit > 203a204,207 > + if [[ ${CTARGET} == "mipsel-unknown-linux-gnu" ]] ; then > + sed -i 's/\(__WORDSIZE.\+\)\(32\|64\)$/\1_MIPS_SZPTR/' \ > + "${D}"/$(alt_headers)/bits/wordsize.h || die "restore wordsize.h failed" > + fi > This change is for O32. Please look into the ebuild if you want know the change on N32. Hope this can help you ：）
well mips is a huge pita to crack for headers targets. it likes to throw -mabi= everywhere possible, and basically refuses to build unless that is defined. http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_unpack.eblit?r1=1.11&r2=1.12 http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_compile.eblit?r1=1.16&r2=1.17 http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_install.eblit?r1=1.12&r2=1.13
*** Bug 323737 has been marked as a duplicate of this bug. ***
