Bug 25672 - [4.9 Regression] cross build's libgcc picks up CFLAGS
Summary: [4.9 Regression] cross build's libgcc picks up CFLAGS
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: 5.0
Assignee: Aldy Hernandez
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: build, patch
Depends on:
Blocks:
 
Reported: 2006-01-04 16:04 UTC by Pawel Sikora
Modified: 2016-08-03 08:11 UTC (History)
4 users (show)

See Also:
Host: i686-pld-linux
Target: x86_64-pc-mingw32
Build: i686-pld-linux
Known to work: 4.0.2, 4.4.0, 5.1.0
Known to fail: 4.1.2, 4.2.0, 4.3.0, 4.5.2, 4.6.4, 4.7.1, 4.9.4
Last reconfirmed: 2006-08-17 19:24:06


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sikora 2006-01-04 16:04:53 UTC
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'
Comment 1 Andrew Pinski 2006-01-04 16:41:11 UTC
Resummaryizing to make clearer.
Comment 2 Pawel Sikora 2006-01-05 02:45:00 UTC
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
Comment 3 Andrew Pinski 2006-01-05 02:49:10 UTC
(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.
Comment 4 Pawel Sikora 2006-01-05 03:01:07 UTC
(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.
Comment 5 Pawel Sikora 2006-01-08 18:29:41 UTC
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 =
Comment 6 Pawel Sikora 2006-05-04 16:15:52 UTC
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?
Comment 7 Andrew Pinski 2006-05-05 09:19:34 UTC
(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@.
Comment 8 Pawel Sikora 2006-05-05 11:52:57 UTC
patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html
Comment 9 Pawel Sikora 2006-06-17 19:24:15 UTC
patch posted on gcc-patches over month ago. still no response.
Comment 10 Steven Bosscher 2006-07-30 10:52:02 UTC
Please ping the patch.  Add DJ Delorie to the CC: list, he is a build system maintainer.  You can find his email in MAINTAINERS.
Comment 11 DJ Delorie 2006-07-31 18:07:01 UTC
(1) I can manage my own bugzilla account, thankyouverymuch, and (2) I'm not the only build maintainer.
Comment 12 Paolo Bonzini 2006-08-05 08:05:15 UTC
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.
Comment 13 Pawel Sikora 2006-08-17 19:22:08 UTC
(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?
Comment 14 Paolo Bonzini 2006-08-17 19:24:06 UTC
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.  
Comment 15 Pawel Sikora 2006-08-17 23:39:11 UTC
(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.
Comment 16 Pawel Sikora 2006-10-23 08:11:27 UTC
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

Comment 17 Pawel Sikora 2007-03-19 09:09:53 UTC
4.1.2 release and 4.2.0-RC1 still fails.
4.3 not tested.
Comment 18 Rask Ingemann Lambertsen 2007-09-26 21:06:34 UTC
I ran into this with 4.3 a few weeks ago.
Comment 19 Uroš Bizjak 2008-02-20 18:44:10 UTC
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html needs build maintainer attention. And a ChangeLog!
Comment 20 Paolo Bonzini 2008-02-20 19:32:35 UTC
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
Comment 21 Paolo Bonzini 2008-02-21 08:13:22 UTC
fixed in 4.4.0
Comment 22 Joseph S. Myers 2008-07-04 20:17:03 UTC
Closing 4.1 branch.
Comment 23 Joseph S. Myers 2009-03-31 19:06:27 UTC
Closing 4.2 branch.
Comment 24 Richard Biener 2009-08-04 12:27:27 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 25 Stefan Reinauer 2009-08-22 19:19:30 UTC
This still happens in 4.4.1 for me.
Comment 26 Richard Biener 2010-05-22 18:10:54 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 27 Pawel Sikora 2010-09-26 17:21:01 UTC
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 :/
Comment 28 Richard Biener 2011-06-27 12:14:19 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 29 Jakub Jelinek 2012-03-13 12:47:48 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 30 Richard Biener 2012-03-27 08:38:10 UTC
Does this bug prevail in GCC 4.6.x, 4.7.x and/or trunk?
Comment 31 Pawel Sikora 2012-03-27 18:39:37 UTC
(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.
Comment 32 Richard Biener 2012-07-02 09:25:39 UTC
The 4.5 branch is being closed.
Comment 33 Richard Biener 2013-01-15 15:02:54 UTC
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.
Comment 34 Jakub Jelinek 2013-04-12 15:16:54 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 35 Oleg Endo 2014-05-11 12:28:32 UTC
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...
Comment 36 Andrew Pinski 2014-05-11 12:37:35 UTC
(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.
Comment 37 Oleg Endo 2014-05-11 18:47:53 UTC
(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.
Comment 38 Richard Biener 2014-06-12 13:46:18 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 39 Jakub Jelinek 2014-12-19 13:29:40 UTC
GCC 4.8.4 has been released.
Comment 40 Aldy Hernandez 2015-03-09 20:47:47 UTC
I'll take a look.
Comment 41 Oleg Endo 2015-03-10 07:59:16 UTC
That's nice!  While you're at it, could you maybe also have a look at PR 53579?  It sounds like a similar issue...
Comment 42 Aldy Hernandez 2015-03-10 16:38:25 UTC
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
Comment 43 Aldy Hernandez 2015-03-10 16:40:51 UTC
Fixed in mainline.  Adjusting subject to indicate that this is no longer a GCC 5 regression.
Comment 44 Richard Biener 2015-06-23 08:18:34 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 45 Jakub Jelinek 2015-06-26 19:54:47 UTC
GCC 4.9.3 has been released.
Comment 46 Richard Biener 2016-08-03 08:11:44 UTC
Fixed on GCC 5+