I'm configuring gcc with: ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib --libexecdir=/usr/lib --disable-shared --disable-threads --enable-languages=c,c++ --enable-c99 --enable-long-long --disable-nls --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --enable-multilib --with-headers=/home/users/builder/rpm/BUILD/gcc-4.1-20051230/fake-root/usr/include --without-x --target=ppc64-pld-linux --host=i686-pld-linux --build=i686-pld-linux CFLAGS=-O2 -march=i686 -mtune=pentium4 -ggdb CXXFLAGS=-O2 -march=i686 -mtune=pentium4 -ggdb TEXCONFIG=false it worked fine with gcc-4.0.2. in 4.1 ./xgcc gets wrong cflags (from host). (...) /home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/xgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/ -B/usr/ppc64-pld-linux/bin/ -B/usr/ppc64-pld-linux/lib/ -isystem /usr/ppc64-pld-linux/include -isystem /usr/ppc64-pld-linux/sys-include -O2 -O2 -O2 -march=i686 -mtune=pentium4 -ggdb -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -msdata=none \ -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o cc1: error: unrecognized command line option "-march=i686" ../../gcc/crtstuff.c:1: error: bad value (pentium4) for -mtune= switch make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/gcc'
Resummaryizing to make clearer.
moreover the buildsystem doesn't propagate -I$target-headers-directory specified in configure by --with-headers=$dir and build fails. below log comes from powerpc (host, build: ppc32, target: ppc64): (...) GCC_FOR_TARGET='/home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/xgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/ -B/usr/ppc64-pld-linux/bin/ -B/usr/ppc64-pld-linux/lib/ -isystem /usr/ppc64-pld-linux/include -isystem /usr/ppc64-pld-linux/sys-include' \ mkinstalldirs='/bin/sh ../../gcc/../mkinstalldirs' \ /bin/sh mklibgcc > tmp-libgcc.mk mv tmp-libgcc.mk libgcc.mk TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET " \ /bin/sh ../../gcc/mkconfig.sh tconfig.h ( echo '#ifndef __powerpc64__'; \ echo '#define FLOAT'; \ cat ../../gcc/config/fp-bit.c; \ echo '#endif' ) > fp-bit32.c ( echo '#ifndef __powerpc64__'; \ cat ../../gcc/config/fp-bit.c; \ echo '#endif' ) > dp-bit32.c /home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/xgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20051230/obj-ppc64-pld-linux/./gcc/ -B/usr/ppc64-pld-linux/bin/ -B/usr/ppc64-pld-linux/lib/ -isystem /usr/ppc64-pld- -fsigned-char -ggdb -DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -msdata=none \ -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ../../gcc/crtstuff.c:68: ../../gcc/tsystem.h:90:19: error: stdio.h: No such file or directory ../../gcc/tsystem.h:93:23: error: sys/types.h: No such file or directory ../../gcc/tsystem.h:96:19: error: errno.h: No such file or directory ../../gcc/tsystem.h:103:20: error: string.h: No such file or directory ../../gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory ../../gcc/tsystem.h:105:20: error: unistd.h: No such file or directory ../../gcc/tsystem.h:111:18: error: time.h: No such file or directory make[1]: *** [crtbegin.o] Error 1
(In reply to comment #2) > moreover the buildsystem doesn't propagate -I$target-headers-directory > specified in configure by --with-headers=$dir and build fails. > > below log comes from powerpc (host, build: ppc32, target: ppc64): That is because people are now building normally --with-sysroot for crosses but that is a different bug than this one.
(In reply to comment #3) > (In reply to comment #2) > > moreover the buildsystem doesn't propagate -I$target-headers-directory > > specified in configure by --with-headers=$dir and build fails. > > > > below log comes from powerpc (host, build: ppc32, target: ppc64): > > That is because people are now building normally --with-sysroot for crosses but > that is a different bug than this one. > I known the 'sysroot' option but it has a side effect - a hardcoded sysroot path in binaries. The 'headers' option hasn't similar impact. I'm building glibc headers for target in temporary dir and can't hardcode (via sysroot option) this dir in the final crossgcc.
hmm, CFLAGS_FOR_TARGET picks up CFLAGS. --- gcc-4.1-20060106/Makefile.in.orig 2005-12-15 15:02:02.000000000 +0100 +++ gcc-4.1-20060106/Makefile.in 2006-01-08 19:27:18.406458250 +0100 @@ -329,9 +329,9 @@ # CFLAGS will be just -g. We want to ensure that TARGET libraries # (which we know are built with gcc) are built with optimizations so # prepend -O2 when setting CFLAGS_FOR_TARGET. -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) +CFLAGS_FOR_TARGET = -O2 $(SYSROOT_CFLAGS_FOR_TARGET) SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ -CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) +CXXFLAGS_FOR_TARGET = -O2 $(SYSROOT_CFLAGS_FOR_TARGET) LIBCFLAGS_FOR_TARGET = $(CFLAGS_FOR_TARGET) LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates LDFLAGS_FOR_TARGET =
nobody cares about this bad flags pickup? (In reply to comment #5) > hmm, CFLAGS_FOR_TARGET picks up CFLAGS. > > --- gcc-4.1-20060106/Makefile.in.orig 2005-12-15 15:02:02.000000000 +0100 > +++ gcc-4.1-20060106/Makefile.in 2006-01-08 19:27:18.406458250 +0100 > @@ -329,9 +329,9 @@ > # CFLAGS will be just -g. We want to ensure that TARGET libraries > # (which we know are built with gcc) are built with optimizations so > # prepend -O2 when setting CFLAGS_FOR_TARGET. > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > +CFLAGS_FOR_TARGET = -O2 $(SYSROOT_CFLAGS_FOR_TARGET) > SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ > -CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > +CXXFLAGS_FOR_TARGET = -O2 $(SYSROOT_CFLAGS_FOR_TARGET) > LIBCFLAGS_FOR_TARGET = $(CFLAGS_FOR_TARGET) > LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates > LDFLAGS_FOR_TARGET = > nobody cares?
(In reply to comment #6) > nobody cares about this bad flags pickup? > (In reply to comment #5) > > hmm, CFLAGS_FOR_TARGET picks up CFLAGS. Nobody else has ran into this and the patch was not posted to gcc-patches@.
patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html
patch posted on gcc-patches over month ago. still no response.
Please ping the patch. Add DJ Delorie to the CC: list, he is a build system maintainer. You can find his email in MAINTAINERS.
(1) I can manage my own bugzilla account, thankyouverymuch, and (2) I'm not the only build maintainer.
The patch is wrong, you need something like -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) and similarly for CXXFLAGS.
(In reply to comment #12) > The patch is wrong, you need something like > > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > and similarly for CXXFLAGS. > this patch works for me. will anybody commit?
Please post to GCC Patches -- I am not a maintainer so I can't approve it anyway. Also, you need a ChangeLog entry, and the CXXFLAGS_FOR_TARGET needs the same treatment.
(In reply to comment #13) > (In reply to comment #12) > > The patch is wrong, you need something like > > > > -CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > +CFLAGS_FOR_TARGET = -O2 $(LIBCFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) > > > > and similarly for CXXFLAGS. > > > > this patch works for me. will anybody commit? > argh, i've tested wrong patch. yours version doesn't work because of LIBCFLAGS=$(CFLAGS) in Makefile.in:290.
Subject: Re: cross build's libgcc picks up CFLAGS lianghua xu napisał(a): > did you save this bug? I am failled in this trouble 2 weeks since I > making the > cross tools for arm-elf-tools under CYGWIN on XP os. any advise, thank you > very much. i'm using this patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672#c5
4.1.2 release and 4.2.0-RC1 still fails. 4.3 not tested.
I ran into this with 4.3 a few weeks ago.
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html needs build maintainer attention. And a ChangeLog!
Subject: Re: [4.1/4.2/4.3/4.4 regression] cross build's libgcc picks up CFLAGS ubizjak at gmail dot com wrote: > ------- Comment #19 from ubizjak at gmail dot com 2008-02-20 18:44 ------- > Patch at http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html needs build > maintainer attention. And a ChangeLog! should be fixed by today's patch for PR/32009. Paolo
fixed in 4.4.0
Closing 4.1 branch.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
This still happens in 4.4.1 for me.
GCC 4.3.5 is being released, adjusting target milestone.
this bug still exists on current 4.5 branch and probably on trunk. e.g. for mingw64 cross compilation libgcc's configure fails with: (...) checking for suffix of object files... configure: error: in `/home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/x86_64-pc-mingw32/libgcc': configure: error: cannot compute suffix of object files: cannot compile config.log contains: (...) configure:3020: /home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/./gcc/xgcc -B/home/users/pluto/rpm/BUILD/gcc-4.5.1/BUILDDIR/./gcc/ -L/usr/x86_64-pc-mingw32/lib -L/usr/mingw/lib -isystem /usr/x86_64-pc-mingw32/include -isystem /usr/mingw/include -B/usr/x86_64-pc-mingw32/bin/ -B/usr/x86_64-pc-mingw32/lib/ -isystem /usr/x86_64-pc-mingw32/include -isystem /usr/x86_64-pc-mingw32/sys-include -o conftest -g -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-3 -g2 conftest.c >&5 conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set configure:3023: $? = 1 as you can see libgcc's configure uses CFLAGS (-O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-3 -g2) passed to top-level configure script :/
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
Does this bug prevail in GCC 4.6.x, 4.7.x and/or trunk?
(In reply to comment #30) > Does this bug prevail in GCC 4.6.x, 4.7.x and/or trunk? i've configured 4.7.0-RC2 for sparc64 target on x86_64 host with: CFLAGS="-O1 -g0 -march=corei7-avx" ./configure.... and the build fails in libgcc as usual: (...) checking for sparc64-gnu-linux-gcc... /home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/./gcc/xgcc -B/home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/./gcc/ -B/opt/gcc47-sparc64/sparc64-gnu-linux/bin/ -B/opt/gcc47-sparc64/sparc64-gnu-linux/lib/ -isystem /opt/gcc47-sparc64/sparc64-gnu-linux/include -isystem /opt/gcc47-sparc64/sparc64-gnu-linux/sys-include checking for suffix of object files... configure: error: in `/home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/sparc64-gnu-linux/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make: *** [configure-target-libgcc] Error 1 config.log says: xgcc: error: unrecognized command line option '-march=corei7-avx' so, the toplevel CFLAGS are pulled into target cflags.
The 4.5 branch is being closed.
Re-confirmed on the 4.7 branch. configury now has # During gcc bootstrap, if we use some random cc for stage1 then CFLAGS # might be empty or "-g". We don't require a C++ compiler, so CXXFLAGS # might also be empty (or "-g", if a non-GCC C++ compiler is in the path). # We want to ensure that TARGET libraries (which we know are built with # gcc) are built with "-O2 -g", so include those options when setting # CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET. if test "x$CFLAGS_FOR_TARGET" = x; then CFLAGS_FOR_TARGET=$CFLAGS case " $CFLAGS " in *" -O2 "*) ;; *) CFLAGS_FOR_TARGET="-O2 $CFLAGS" ;; esac case " $CFLAGS " in *" -g "* | *" -g3 "*) ;; *) CFLAGS_FOR_TARGET="-g $CFLAGS" ;; esac fi AC_SUBST(CFLAGS_FOR_TARGET) ... (likewise CXXFLAGS_FOR_TARGET) but substituting CFLAGS here is certainly wrong. The above seems to be overeagerly trying to honor CFLAGS more broadly as a convenience. But doing so when build != target looks wrong. As alternative it should be documented that CFLAGS also applies to target libraries unless CFLAGS_FOR_TARGET is set.
GCC 4.6.4 has been released and the branch has been closed.
Just ran into the same issue with trunk r210305, while building a cross SH on OSX. The newly merged wide-int code contains some things, which clang considers an error. Setting export CFLAGS="-fheinous-gnu-extensions" export CXXFLAGS="-fheinous-gnu-extensions" fixes that, but then one need also to set e.g. export CFLAGS_FOR_TARGET="-O2" export CXXFLAGS_FOR_TARGET="-O2" or else -fheinous-gnu-extensions will be passed to the xgcc. This really should be documented somewhere...
(In reply to Oleg Endo from comment #35) > Just ran into the same issue with trunk r210305, while building a cross SH > on OSX. The newly merged wide-int code contains some things, which clang > considers an error. Setting > export CFLAGS="-fheinous-gnu-extensions" > export CXXFLAGS="-fheinous-gnu-extensions" > > fixes that, but then one need also to set e.g. > export CFLAGS_FOR_TARGET="-O2" > export CXXFLAGS_FOR_TARGET="-O2" > > or else -fheinous-gnu-extensions will be passed to the xgcc. > This really should be documented somewhere... Can you file a bug about these errors? Are we sure it is a gnu extension issue or just clang thinks it is a gnu extension.
(In reply to Andrew Pinski from comment #36) > Can you file a bug about these errors? PR 61146 > Are we sure it is a gnu extension > issue or just clang thinks it is a gnu extension. No idea, I haven't looked into the details.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
I'll take a look.
That's nice! While you're at it, could you maybe also have a look at PR 53579? It sounds like a similar issue...
Author: aldyh Date: Tue Mar 10 16:37:53 2015 New Revision: 221326 URL: https://gcc.gnu.org/viewcvs?rev=221326&root=gcc&view=rev Log: PR bootstrap/25672 * configure.ac: Do not initialize CFLAGS_FOR_TARGET from CFLAGS if cross-compiling. Similarly for CXX_FOR_TARGET. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
Fixed in mainline. Adjusting subject to indicate that this is no longer a GCC 5 regression.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
Fixed on GCC 5+