Two build != host fixes

On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
> Hi,
> 
> I'm having problems with that patch.

Sorry to hear that.

> I try to start at X86_64-linux-gnu, and I want to get the GCC running on arm-linux-gnueabihf.
> I grabbed system headers and libraries from the target and put it in the prefix path.
> 
> In the first step I do
> 
> ../gcc-4.9-20131208/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> 
> This GCC runs on PC and generates arm-linux-gnueabihf executables.
> 
> Then I try this
> 
> ../gcc-4.9-20131208/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> 
> But It fails because auto-build.h contains nonsense. That is probably because almost every check
> has a fatal error #include <gmp.h> not found.
> 
> I personally prefer to have gmp, mpfr, mpc in-tree (using contrib/download_prerequisites).
> 
> I experimented a bit and at least this attached patch improves the situation for me.
> 
> Maybe I never had any problems with GMP before, because the in-tree configuration of GMP does -DNO_ASM ?

GMPINC really shouldn't be used to find build headers, since it is used
to find host headers.  See the top level Makefile.in.  When gmp has
been installed, using GMPINC means you pull in a whole lot of host
headers for the build compiler.  Which might work in rare cases, but
it's a lot more likely to fail.  Even with in-tree gmp, how do you get
things like GMP_LIMB_BITS correct if your build machine is 64-bit and
your host is 32-bit?  (Perhaps there is some build magic that allows
this to work, I'll investigate when I get back from vacation.)

Incidentally, we've been using a couple of other patches for
build != host that I haven't posted because I wasn't sure who authored
them.  It's possible the first one might help you.

On Wed, 11 Dec 2013 23:11:46, Alan Modra wrote:
>
> On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> I'm having problems with that patch.
>
> Sorry to hear that.
>

Never mind.

I have similar patches, but I did not 
>> I try to start at X86_64-linux-gnu, and I want to get the GCC running on arm-linux-gnueabihf.
>> I grabbed system headers and libraries from the target and put it in the prefix path.
>>
>> In the first step I do
>>
>> ../gcc-4.9-20131208/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
>>
>> This GCC runs on PC and generates arm-linux-gnueabihf executables.
>>
>> Then I try this
>>
>> ../gcc-4.9-20131208/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
>>
>> But It fails because auto-build.h contains nonsense. That is probably because almost every check
>> has a fatal error #include <gmp.h> not found.
>>
>> I personally prefer to have gmp, mpfr, mpc in-tree (using contrib/download_prerequisites).
>>
>> I experimented a bit and at least this attached patch improves the situation for me.
>>
>> Maybe I never had any problems with GMP before, because the in-tree configuration of GMP does -DNO_ASM ?
>
> GMPINC really shouldn't be used to find build headers, since it is used
> to find host headers. See the top level Makefile.in. When gmp has
> been installed, using GMPINC means you pull in a whole lot of host
> headers for the build compiler. Which might work in rare cases, but
> it's a lot more likely to fail. Even with in-tree gmp, how do you get
> things like GMP_LIMB_BITS correct if your build machine is 64-bit and
> your host is 32-bit? (Perhaps there is some build magic that allows
> this to work, I'll investigate when I get back from vacation.)
>

I do not know, but until last week the only problem was a missing SSIZE_MAX
in gcc/config/host-linux.c (glimits.h does not define this, and fix-include replaced mine!)

We need the auto-build only to build something that translates .md files to .c,
so I would'nt care about GMP, but some other things, like the right prototype for
printf make a difference.

now the auto-build.h has 
#define HAVE_DECL_SBRK 0

last week that was
#define HAVE_DECL_SBRK 1

I can give you my sys-root files, and you can play with it if you like.


> Incidentally, we've been using a couple of other patches for
> build != host that I haven't posted because I wasn't sure who authored
> them. It's possible the first one might help you.
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index aad927c..7995e64 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -747,7 +747,8 @@ BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS)
>
> # Native linker and preprocessor flags. For x-fragment overrides.
> BUILD_LDFLAGS=@BUILD_LDFLAGS@
> -BUILD_CPPFLAGS=$(ALL_CPPFLAGS)
> +BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
> + -I$(srcdir)/../include $(CPPINC)
>

I did not have this one.
What is it good for?

> # Actual name to use when installing a native compiler.
> GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
> diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in
> index 57f9009..e1d3ed6 100644
> --- a/gcc/ada/gcc-interface/Make-lang.in
> +++ b/gcc/ada/gcc-interface/Make-lang.in
> @@ -625,7 +625,7 @@ ada.tags: force
> ada/doctools/xgnatugn$(build_exeext): ada/xgnatugn.adb
> -$(MKDIR) ada/doctools
> $(CP) $^ ada/doctools
> - cd ada/doctools && $(GNATMAKE) -q xgnatugn
> + cd ada/doctools && gnatmake -q xgnatugn
>

Yes, I also have that. It's a show-stopper for Ada.

> # Note that doc/gnat_ugn.texi and doc/projects.texi do not depend on
> # xgnatugn being built so we can distribute a pregenerated doc/gnat_ugn.info
> diff --git a/gnattools/Makefile.in b/gnattools/Makefile.in
> index 794d374..6b0d5e8 100644
> --- a/gnattools/Makefile.in
> +++ b/gnattools/Makefile.in
> @@ -23,6 +23,7 @@ SHELL = @SHELL@
> srcdir = @srcdir@
> libdir = @libdir@
> build = @build@
> +host = @host@
> target = @target@
> prefix = @prefix@
> INSTALL = @INSTALL@
> @@ -31,6 +32,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
>
> # Nonstandard autoconf-set variables.
> LN_S=@LN_S@
> +host_alias=@host_alias@
> target_noncanonical=@target_noncanonical@
>
> # Variables for the user (or the top level) to override.
> @@ -183,7 +185,11 @@ regnattools: $(GCC_DIR)/stamp-gnatlib-rts
> # put the host RTS dir first in the PATH to hide the default runtime
> # files that are among the sources
> # FIXME: This should be done in configure.
> +ifeq ($(host), $(build))
> RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib )))
> +else
> +RTS_DIR:=$(strip $(subst \,/,$(shell $(host_alias)-gnatls -v | grep adalib )))
> +endif
> gnattools-cross: $(GCC_DIR)/stamp-tools
> # gnattools1-re
> $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
>
> --
> Alan Modra
> Australia Development Lab, IBM

On 11 Dec 2013, at 13:11, Bernd Edlinger wrote:
> I did not have this one.
> What is it good for?
> 
>> # Actual name to use when installing a native compiler.
>> GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
>> diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in
>> index 57f9009..e1d3ed6 100644
>> --- a/gcc/ada/gcc-interface/Make-lang.in
>> +++ b/gcc/ada/gcc-interface/Make-lang.in
>> @@ -625,7 +625,7 @@ ada.tags: force
>> ada/doctools/xgnatugn$(build_exeext): ada/xgnatugn.adb
>> -$(MKDIR) ada/doctools
>> $(CP) $^ ada/doctools
>> - cd ada/doctools && $(GNATMAKE) -q xgnatugn
>> + cd ada/doctools && gnatmake -q xgnatugn
>> 
> 
> Yes, I also have that. It's a show-stopper for Ada.

I have some more fixes for Ada cross-builds that Eric commented on but need a little more work - will try to re-test this evening and re-post tomorrow.
Iain

On Wed, Dec 11, 2013 at 02:11:49PM +0100, Bernd Edlinger wrote:
> We need the auto-build only to build something that translates .md files to .c,
> so I would'nt care about GMP, but some other things, like the right prototype for
> printf make a difference.

Right, but when you get some of the HAVE_* wrong, libiberty for the
build compiler provides some of the "missing" functions and
declarations.  The declarations can clash with system header
declarations giving you bootstrap failures for no good reason..

> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index aad927c..7995e64 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > @@ -747,7 +747,8 @@ BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS)
> >
> > # Native linker and preprocessor flags. For x-fragment overrides.
> > BUILD_LDFLAGS=@BUILD_LDFLAGS@
> > -BUILD_CPPFLAGS=$(ALL_CPPFLAGS)
> > +BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
> > + -I$(srcdir)/../include $(CPPINC)
> >
> 
> I did not have this one.
> What is it good for?

It fixes another case of host header directories being searched for
the build compiler.  Important when GMPINC and other *INC point at
installed locations for the host compiler.  Trouble is, you don't just
get the headers you want (eg. gmp.h) but all the other host headers
too.