diff mbox

Two build != host fixes

Message ID 20131217232839.GB1864@bubble.grove.modra.org
State New
Headers show

Commit Message

Alan Modra Dec. 17, 2013, 11:28 p.m. UTC 
On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
> the reason for this is overwriting GMPINC for the auto-build generation, because
> many test scripts include <gmp.h> which fails now completely (it is not installed,
> I have it in-tree).

Yes, I understand the reason why your setup is failing.  Please try
this patch.

Comments

Bernd Edlinger Dec. 18, 2013, 1:32 p.m. UTC | #1 
Hi,

On Wed, 18 Dec 2013 09:58:39, Alan Modra wrote:
>
> On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
>> the reason for this is overwriting GMPINC for the auto-build generation, because
>> many test scripts include <gmp.h> which fails now completely (it is not installed,
>> I have it in-tree).
>
> Yes, I understand the reason why your setup is failing. Please try
> this patch.
>
> Index: gcc/configure.ac
> ===================================================================
> --- gcc/configure.ac (revision 206009)
> +++ gcc/configure.ac (working copy)
> @@ -1529,8 +1529,13 @@
> /* | [A-Za-z]:[\\/]* ) realsrcdir=${srcdir};;
> *) realsrcdir=../${srcdir};;
> esac
> + # Clearing GMPINC is necessary to prevent host headers being
> + # used by the build compiler. Defining GENERATOR_FILE stops
> + # system.h from including gmp.h.
> CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
> - LDFLAGS="${LDFLAGS_FOR_BUILD}" GMPINC="" \
> + CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
> + LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
> + GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
> ${realsrcdir}/configure \
> --enable-languages=${enable_languages-all} \
> --target=$target_alias --host=$build_alias --build=$build_alias
>
> --
> Alan Modra
> Australia Development Lab, IBM

Yes. It works. Thanks!


g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include -I/home/ed/gnu/x/gcc-build-arm-linux-gnueabihf-cross/./gmp -I/home/ed/gnu/x/gcc-4.9-20131215/gmp -I/home/ed/gnu/x/gcc-build-arm-linux-gnueabihf-cross/./mpfr -I/home/ed/gnu/x/gcc-4.9-20131215/mpfr -I/home/ed/gnu/x/gcc-4.9-20131215/mpc/src  -I../../gcc-4.9-20131215/gcc/../libdecnumber -I../../gcc-4.9-20131215/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-4.9-20131215/gcc/../libbacktrace    \
                -o build/gengtype.o ../../gcc-4.9-20131215/gcc/gengtype.c


I wonder if the GMPINC="" is still necessary, as the actual host g++ invocation also has GMP-directories
but does not use them because of the -DGENERATOR_FILE.


Bernd.
Alan Modra Dec. 19, 2013, 10:11 a.m. UTC | #2 
On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
> I wonder if the GMPINC="" is still necessary, as the actual host g++ invocation also has GMP-directories
> but does not use them because of the -DGENERATOR_FILE.

The issue isn't finding gmp.h, it's finding other host headers you
don't want.  Clearly, --with-gmp and similar options are for finding
host libraries and headers.  install.texi even says so!

To give an example of what can go wrong, suppose someone specifies
--with-gmp=/sysroot_for_host for an installed gmp.  Now I know that
it's unnecessary to specify --with-gmp if it's at the default install
location, but many people blindly follow recipes.  What's more,
specifying --with-gmp to the default works fine when build == host.
So it doesn't seem wrong to me to specify --with-gmp (even needlessly
to the default) when build != host.

The trouble is that GMPINC is then /sysroot_for_host/include, which is
where you find all the other host headers, not just gmp.h..
Bernd Edlinger Dec. 19, 2013, 10:50 a.m. UTC | #3 
On Thu, 19 Dec 2013 20:41:43, Alan Modra wrote:
>
> On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
>> I wonder if the GMPINC="" is still necessary, as the actual host g++ invocation also has GMP-directories
>> but does not use them because of the -DGENERATOR_FILE.
>
> The issue isn't finding gmp.h, it's finding other host headers you
> don't want. Clearly, --with-gmp and similar options are for finding
> host libraries and headers. install.texi even says so!
>
> To give an example of what can go wrong, suppose someone specifies
> --with-gmp=/sysroot_for_host for an installed gmp. Now I know that
> it's unnecessary to specify --with-gmp if it's at the default install
> location, but many people blindly follow recipes. What's more,
> specifying --with-gmp to the default works fine when build == host.
> So it doesn't seem wrong to me to specify --with-gmp (even needlessly
> to the default) when build != host.
>
> The trouble is that GMPINC is then /sysroot_for_host/include, which is
> where you find all the other host headers, not just gmp.h..
>

OK, thanks, I understand. I'm just curious...

Isn't the actual invocation of the build-g++ also including /sysroot_for_host/include
in that case? Why doesn't this cause problems then?


Bernd.

> --
> Alan Modra
> Australia Development Lab, IBM
Alan Modra Dec. 19, 2013, 9:27 p.m. UTC | #4 
On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
> Isn't the actual invocation of the build-g++ also including /sysroot_for_host/include
> in that case? Why doesn't this cause problems then?

Yes, and that causes failures too.  BUILD_CPPFLAGS is the culprit.
See http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
Bernd Edlinger Dec. 20, 2013, 12:07 p.m. UTC | #5 
----------------------------------------
> Date: Fri, 20 Dec 2013 07:57:02 +1030
> From: amodra@gmail.com
> To: bernd.edlinger@hotmail.de
> CC: gcc-patches@gcc.gnu.org; jakub@redhat.com; dj@redhat.com; ebotcazou@adacore.com
> Subject: Re: Two build != host fixes
>
> On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
>> Isn't the actual invocation of the build-g++ also including /sysroot_for_host/include
>> in that case? Why doesn't this cause problems then?
>
> Yes, and that causes failures too. BUILD_CPPFLAGS is the culprit.
> See http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
>
> --
> Alan Modra
> Australia Development Lab, IBM

Ok, now I understand:
The change with  GMPINC="" is just incomplete, without the other patch.

When I apply the other patch too, I get this (obviously cleaner) build-g++ invocations:
g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
                -o build/gengtype.o ../../gcc-4.9-20131215/gcc/gengtype.c
flex  -ogengtype-lex.c ../../gcc-4.9-20131215/gcc/gengtype-lex.l && { \
          echo '#include "bconfig.h"'> gengtype-lex.c.tmp; \
          cat gengtype-lex.c>> gengtype-lex.c.tmp; \
          mv gengtype-lex.c.tmp gengtype-lex.c; \
        }
g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
                -o build/gengtype-lex.o gengtype-lex.c
g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
                -o build/gengtype-parse.o ../../gcc-4.9-20131215/gcc/gengtype-parse.c
g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
                -o build/gengtype-state.o ../../gcc-4.9-20131215/gcc/gengtype-state.c


Regards
Bernd.
Bernd Edlinger Jan. 7, 2014, 3:45 p.m. UTC | #6 
Hi Alan,


This issue is not yet resolved, in the moment this cross-compiler issue looks like a regression.

But I have tried your follow-up patches, and they make sense for me:

 http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01544.html

How can we proceed?

Regards
Bernd.


>>
>> On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
>>> Isn't the actual invocation of the build-g++ also including /sysroot_for_host/include
>>> in that case? Why doesn't this cause problems then?
>>
>> Yes, and that causes failures too. BUILD_CPPFLAGS is the culprit.
>> See http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>
> Ok, now I understand:
> The change with  GMPINC="" is just incomplete, without the other patch.
>
> When I apply the other patch too, I get this (obviously cleaner) build-g++ invocations:
> g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
>                 -o build/gengtype.o ../../gcc-4.9-20131215/gcc/gengtype.c
> flex  -ogengtype-lex.c ../../gcc-4.9-20131215/gcc/gengtype-lex.l && { \
>           echo '#include "bconfig.h"'> gengtype-lex.c.tmp; \
>           cat gengtype-lex.c>> gengtype-lex.c.tmp; \
>           mv gengtype-lex.c.tmp gengtype-lex.c; \
>         }
> g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
>                 -o build/gengtype-lex.o gengtype-lex.c
> g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
>                 -o build/gengtype-parse.o ../../gcc-4.9-20131215/gcc/gengtype-parse.c
> g++ -c -DIN_GCC     -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc -I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include -I../../gcc-4.9-20131215/gcc/../libcpp/include \
>                 -o build/gengtype-state.o ../../gcc-4.9-20131215/gcc/gengtype-state.c
>
>
> Regards
> Bernd.
Bernd Edlinger Jan. 22, 2014, 2:16 p.m. UTC | #7 
Hi,


it is quite late in P3 now, so how about the attached patch?

This would return to the status quo before your patch, where $GMPINC must be != sysroot.


Bernd.

> Date: Tue, 7 Jan 2014 16:45:15 +0100
>
> Hi Alan,
>
>
> This issue is not yet resolved, in the moment this cross-compiler issue looks like a regression.
>
> But I have tried your follow-up patches, and they make sense for me:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01544.html
>
> How can we proceed?
>
> Regards
> Bernd.
>
>
Maciej W. Rozycki March 26, 2014, 9:43 p.m. UTC | #8 
Alan,

On Tue, 17 Dec 2013, Alan Modra wrote:

> On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
> > the reason for this is overwriting GMPINC for the auto-build generation, because
> > many test scripts include <gmp.h> which fails now completely (it is not installed,
> > I have it in-tree).
> 
> Yes, I understand the reason why your setup is failing.  Please try
> this patch.
> 
> Index: gcc/configure.ac
> ===================================================================
> --- gcc/configure.ac	(revision 206009)
> +++ gcc/configure.ac	(working copy)
> @@ -1529,8 +1529,13 @@
>  	/* | [A-Za-z]:[\\/]* ) realsrcdir=${srcdir};;
>  	*) realsrcdir=../${srcdir};;
>  	esac
> +	# Clearing GMPINC is necessary to prevent host headers being
> +	# used by the build compiler.  Defining GENERATOR_FILE stops
> +	# system.h from including gmp.h.
>  	CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
> -	LDFLAGS="${LDFLAGS_FOR_BUILD}" GMPINC="" \
> +	CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
> +	LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
> +	GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
>  	${realsrcdir}/configure \
>  		--enable-languages=${enable_languages-all} \
>  		--target=$target_alias --host=$build_alias --build=$build_alias

 Can you please backport this change to 4.8 too, to fix the build 
regression discussed here introduced by the previous change that did get 
backported?

 Thanks,

  Maciej
diff mbox

Patch

Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 206009)
+++ gcc/configure.ac	(working copy)
@@ -1529,8 +1529,13 @@ 
 	/* | [A-Za-z]:[\\/]* ) realsrcdir=${srcdir};;
 	*) realsrcdir=../${srcdir};;
 	esac
+	# Clearing GMPINC is necessary to prevent host headers being
+	# used by the build compiler.  Defining GENERATOR_FILE stops
+	# system.h from including gmp.h.
 	CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
-	LDFLAGS="${LDFLAGS_FOR_BUILD}" GMPINC="" \
+	CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
+	LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
+	GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
 	${realsrcdir}/configure \
 		--enable-languages=${enable_languages-all} \
 		--target=$target_alias --host=$build_alias --build=$build_alias