[PATCH] Fix fixincludes for canadian cross builds
Hi,
I noticed that there is a subtle problem with build!=host
configurations.
That is, the fixinclude machinery is using the path that would
work on the target system to find the headers that need to be
fixed, but the build machine can have different header files than
the target machine, even if th are at the same location. This can
theoretically cause a mis-compilation of the target libraries.
However the mkheaders script works on the target, and would fix it up,
but the target libraries are not rebuilt, and they may have used the
wrong fixed headers.
To fix this inconsistency I would like to introduce a new make
variable BUILD_SYSTEM_HEADER_DIR that is identical to SYSTEM_HEADER_DIR
if build==host and which is CROSS_SYSTEM_HEADER_DIR for canadian cross
configs.
Only mkheaders.conf uses SYSTEM_HEADER_DIR because it runs on the
host system, all other places should use BUILD_SYSTEM_HEADER_DIR.
I tested this change with different arm-linux-gnueabihf cross
compilers, and verified that mkheaders still works on the host system.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-02-06 Bernd Edlinger
* Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
(LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use BUILD_SYSTEM_HEADER_DIR
instead of SYSTEM_HEADER_DIR.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 245184)
+++ gcc/Makefile.in (working copy)
@@ -517,11 +517,18 @@
# macro is also used in a double-quoted context.
SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
+# Path to the system headers on the build machine
+ifeq ($(build),$(host))
+BUILD_SYSTEM_HEADER_DIR = $(SYSTEM_HEADER_DIR)
+else
+BUILD_SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
+endif
+
# Control whether to run fixincludes.
STMP_FIXINC = @STMP_FIXINC@
# Test to see whether exists in the system header files.
-LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
+LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]
# Directory for prefix to system directories, for
# each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
@@ -572,7 +579,7 @@
else
ifeq ($(enable_multiarch),auto)
# SYSTEM_HEADER_DIR is makefile syntax, cannot be evaluated in configure.ac
-if_multiarch = $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
+if_multiarch = $(if $(wildcard $(shell echo $(BUILD_SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
else
if_multiarch =
endif
@@ -2990,11 +2997,11 @@
sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed$${multi_dir}; \
- if ! $(inhibit_libc) && test ! -d ${SYSTEM_HEADER_DIR}; then \
+ if ! $(inhibit_libc) && test ! -d ${BUILD_SYSTEM_HEADER_DIR}; then \
echo The directory that should contain system headers does not exist: >&2 ; \
- echo " ${SYSTEM_HEADER_DIR}" >&2 ; \
+ echo " ${BUILD_SYSTEM_HEADER_DIR}" >&2 ; \
tooldir_sysinc=`echo "${gcc_tooldir}/sys-include" | sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`; \
- if test "x${SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
+ if test "x${BUILD_SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
then sleep 1; else exit 1; fi; \
fi; \
$(mkinstalldirs) $${fix_dir}; \
@@ -3005,7 +3012,7 @@
export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
cd $(build_objdir)/fixincludes && \
$(SHELL) ./fixinc.sh "$${gcc_dir}/$${fix_dir}" \
- $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
+ $(BUILD_SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
rm -f $${fix_dir}/syslimits.h; \
if [ -f $${fix_dir}/limits.h ]; then \
mv $${fix_dir}/limits.h $${fix_dir}/syslimits.h; \
Re: [PATCH] Fix fixincludes for canadian cross builds
On 02/06/17 10:44, Bernd Edlinger wrote: > I tested this change with different arm-linux-gnueabihf cross > compilers, and verified that mkheaders still works on the host system. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? As long as you certify that this is correct for all systems we care about: +BUILD_SYSTEM_HEADER_DIR = ` +echo $(CROSS_SYSTEM_HEADER_DIR) | \ +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` that is pretty obtuse sed-speak to me. I suggest a comment explaining what sed is supposed to be doing. What should "$(CROSS_SYSTEM_HEADER_DIR)" look like?
Re: [PATCH] Fix fixincludes for canadian cross builds
On 02/18/17 00:37, Bruce Korb wrote: > On 02/06/17 10:44, Bernd Edlinger wrote: >> I tested this change with different arm-linux-gnueabihf cross >> compilers, and verified that mkheaders still works on the host system. >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >> Is it OK for trunk? > > As long as you certify that this is correct for all systems we care about: > > +BUILD_SYSTEM_HEADER_DIR = ` > +echo $(CROSS_SYSTEM_HEADER_DIR) | \ > +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` > > that is pretty obtuse sed-speak to me. I suggest a comment > explaining what sed is supposed to be doing. What should > "$(CROSS_SYSTEM_HEADER_DIR)" look like? > I took it just from a few lines above, so I thought that comment would sufficiently explain the syntax: # autoconf sets SYSTEM_HEADER_DIR to one of the above. # Purge it of unnecessary internal relative paths # to directories that might not exist yet. # The sed idiom for this is to repeat the search-and-replace until it doesn't match, using :a ... ta. # Use single quotes here to avoid nested double- and backquotes, this # macro is also used in a double-quoted context. SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` But I guess it would not hurt to just repeat "Purge it of unnecessary internal relative paths" here as well. CROSS_SYSTEM_HEADER_DIR is where the target system headers are located on the build system (IOW the system root), that can be something like "CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include" Which may expand to something like that: "/home/ed/gnu/arm-linux-gnueabihf-cross/lib/gcc/arm-linux-gnueabihf/7.0.1/../../../../arm-linux-gnueabihf/sys-include" which the sed script changes then to "/home/ed/gnu/arm-linux-gnueabihf-cross/arm-linux-gnueabihf/sys-include" And in deed, I have put the target header files there on the build machine. But on the target system the include files are simply at "/usr/include" which is the value of SYSTEM_HEADER_DIR, thus SYSTEM_HEADER_DIR is not a path where the headers are visible at the build system, only code that executes on the target system should use SYSTEM_HEADER_DIR. Thanks Bernd.
Re: [PATCH] Fix fixincludes for canadian cross builds
On 02/18/17 01:01, Bernd Edlinger wrote: > On 02/18/17 00:37, Bruce Korb wrote: >> On 02/06/17 10:44, Bernd Edlinger wrote: >>> I tested this change with different arm-linux-gnueabihf cross >>> compilers, and verified that mkheaders still works on the host system. >>> >>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>> Is it OK for trunk? >> >> As long as you certify that this is correct for all systems we care about: >> >> +BUILD_SYSTEM_HEADER_DIR = ` >> +echo $(CROSS_SYSTEM_HEADER_DIR) | \ >> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` >> >> that is pretty obtuse sed-speak to me. I suggest a comment >> explaining what sed is supposed to be doing. What should >> "$(CROSS_SYSTEM_HEADER_DIR)" look like? >> > > I took it just from a few lines above, so I thought that comment would > sufficiently explain the syntax: I confess, I didn't pull a new copy of gcc, sorry. So it looks good to me.
Re: [PATCH] Fix fixincludes for canadian cross builds
Hi, On 20 February 2017 at 18:53, Bruce Korb wrote: > On 02/18/17 01:01, Bernd Edlinger wrote: >> On 02/18/17 00:37, Bruce Korb wrote: >>> On 02/06/17 10:44, Bernd Edlinger wrote: I tested this change with different arm-linux-gnueabihf cross compilers, and verified that mkheaders still works on the host system. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? >>> >>> As long as you certify that this is correct for all systems we care about: >>> >>> +BUILD_SYSTEM_HEADER_DIR = ` >>> +echo $(CROSS_SYSTEM_HEADER_DIR) | \ >>> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` >>> >>> that is pretty obtuse sed-speak to me. I suggest a comment >>> explaining what sed is supposed to be doing. What should >>> "$(CROSS_SYSTEM_HEADER_DIR)" look like? >>> >> >> I took it just from a few lines above, so I thought that comment would >> sufficiently explain the syntax: > > I confess, I didn't pull a new copy of gcc, sorry. > So it looks good to me. We just noticed that this patch brakes canadian cross builds when configured with --with-build-sysroot, since headers are searched into the target sysroot instead of the one specified for builds. Maybe there's a cleaner way to fix this and avoid the duplication but I didn't find another to test if --with-build-sysroot is used. The attached patch fixes the issue. Tested with a Full canadian cross build for i686-w64-mingw32 host and arm-linux-gnueabihf. Thanks Yvan 2017-04-12 Yvan Roux * Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR when configured with --with-build-sysroot. diff --git a/gcc/Makefile.in b/gcc/Makefile.in index e38b726..7aed942 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -520,6 +520,8 @@ SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e 's,[^/]*/\.\.\/,,' # Path to the system headers on the build machine ifeq ($(build),$(host)) BUILD_SYSTEM_HEADER_DIR = $(SYSTEM_HEADER_DIR) +else ifdef SYSROOT_CFLAGS_FOR_TARGET +BUILD_SYSTEM_HEADER_DIR = $(SYSTEM_HEADER_DIR) else BUILD_SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` endif
Re: [PATCH] Fix fixincludes for canadian cross builds
I will be unable to look at this for a couple of weeks, so I leave this to others to look at. On Wed, Apr 12, 2017 at 8:58 AM, Yvan Roux wrote: > Hi, > > On 20 February 2017 at 18:53, Bruce Korb wrote: >> On 02/18/17 01:01, Bernd Edlinger wrote: >>> On 02/18/17 00:37, Bruce Korb wrote: On 02/06/17 10:44, Bernd Edlinger wrote: > I tested this change with different arm-linux-gnueabihf cross > compilers, and verified that mkheaders still works on the host system. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? As long as you certify that this is correct for all systems we care about: +BUILD_SYSTEM_HEADER_DIR = ` +echo $(CROSS_SYSTEM_HEADER_DIR) | \ +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` that is pretty obtuse sed-speak to me. I suggest a comment explaining what sed is supposed to be doing. What should "$(CROSS_SYSTEM_HEADER_DIR)" look like? >>> >>> I took it just from a few lines above, so I thought that comment would >>> sufficiently explain the syntax: >> >> I confess, I didn't pull a new copy of gcc, sorry. >> So it looks good to me. > > > We just noticed that this patch brakes canadian cross builds when > configured with --with-build-sysroot, since headers are searched into > the target sysroot instead of the one specified for builds. > > Maybe there's a cleaner way to fix this and avoid the duplication but > I didn't find another to test if --with-build-sysroot is used. The > attached patch fixes the issue. Tested with a Full canadian cross > build for i686-w64-mingw32 host and arm-linux-gnueabihf. > > Thanks > Yvan > > 2017-04-12 Yvan Roux > >* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR >when configured with --with-build-sysroot.
Re: [PATCH] Fix fixincludes for canadian cross builds
On 04/12/17 17:58, Yvan Roux wrote:
> Hi,
>
> On 20 February 2017 at 18:53, Bruce Korb wrote:
>> On 02/18/17 01:01, Bernd Edlinger wrote:
>>> On 02/18/17 00:37, Bruce Korb wrote:
On 02/06/17 10:44, Bernd Edlinger wrote:
> I tested this change with different arm-linux-gnueabihf cross
> compilers, and verified that mkheaders still works on the host system.
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
As long as you certify that this is correct for all systems we care about:
+BUILD_SYSTEM_HEADER_DIR = `
+echo $(CROSS_SYSTEM_HEADER_DIR) | \
+sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
that is pretty obtuse sed-speak to me. I suggest a comment
explaining what sed is supposed to be doing. What should
"$(CROSS_SYSTEM_HEADER_DIR)" look like?
>>>
>>> I took it just from a few lines above, so I thought that comment would
>>> sufficiently explain the syntax:
>>
>> I confess, I didn't pull a new copy of gcc, sorry.
>> So it looks good to me.
>
>
> We just noticed that this patch brakes canadian cross builds when
> configured with --with-build-sysroot, since headers are searched into
> the target sysroot instead of the one specified for builds.
>
> Maybe there's a cleaner way to fix this and avoid the duplication but
> I didn't find another to test if --with-build-sysroot is used. The
> attached patch fixes the issue. Tested with a Full canadian cross
> build for i686-w64-mingw32 host and arm-linux-gnueabihf.
>
> Thanks
> Yvan
>
> 2017-04-12 Yvan Roux
>
>* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR
>when configured with --with-build-sysroot.
>
Oops, sorry for the breakage...
However I think the patch simply restores the previous behavior, because
ifdef SYSROOT_CFLAGS_FOR_TARGET is always true, even if it's empty,
but it does still not work correctly.
I tried to build a cross with your patch and a --with-build-sysroot
but the target compiler does fix the wrong includes for me:
../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
--enable-languages=c,c++,ada,fortran --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
--with-build-sysroot=/home/ed/gnu/arm-linux-gnueabihf-3
=>
Fixing headers into
/home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed for
arm-unknown-linux-gnueabihf target
Forbidden identifiers: linux unix
Finding directories and links to directories
Searching /usr/include/.
Searching /usr/include/./c++/4.8.4
Searching /usr/include/./numpy
Searching /usr/include/./python2.7/numpy
Making symbolic directory links
Fixing directory /usr/include into
/home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed
but it should fix headers in .../arm-linux-gnueabihf-3/usr/include
I think it would work if I use --with-sysroot together with
--with-build-sysroot in the config above, but why should the
target compiler use --with-sysroot ?
There is no need for that on the target, just the cross-compiler
might need to support that.
I tried to fix some possible combinations of --with-sysroot/
--with-build-sysroot, and moved the logic to the configure
script. When I did that I noticed also some more glitches
when grabbing the TARGET_GLIBC_MAJOR/MINOR defines from sysroot
files.
This updated patch seems to work for me, could you give it a try?
Thanks
Bernd.
2017-04-14 Bernd Edlinger
* configure.ac (SYSTEM_HEADER_DIR, BUILD_SYSTEM_HEADER_DIR,
target_header_dir): Set correctly.
* configure: Regenerated.
* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Use directly.
Index: gcc/configure
===
--- gcc/configure (revision 246899)
+++ gcc/configure (working copy)
@@ -719,6 +719,7 @@ BUILD_CFLAGS
CXX_FOR_BUILD
CC_FOR_BUILD
inhibit_libc
+BUILD_SYSTEM_HEADER_DIR
SYSTEM_HEADER_DIR
ALL
CROSS
@@ -12214,14 +12215,15 @@ done
CROSS=
ALL=all.internal
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
+BUILD_SYSTEM_HEADER_DIR=$SYSTEM_HEADER_DIR
if test "x$with_build_sysroot" != x; then
- build_system_header_dir=$with_build_sysroot'$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
-else
+ BUILD_SYSTEM_HEADER_DIR=$with_build_sysroot'$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+elif test x$host != x$target; then
# This value is used, even on a native system, because
# CROSS_SYSTEM_HEADER_DIR is just
# $(TARGET_SYSTEM_ROOT)$(NATIVE_SYSTEM_HEADER_DIR).
- build_system_header_dir='$(CROSS_SYSTEM_HEADER_DIR)'
+ BUILD_SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)'
fi
if test x$host != x$target
@@ -12228,7 +12230,7 @@ if test x$host != x$target
then
CROSS="-DCROSS_DIRECTORY_STRUCTURE"
ALL=all.cross
- SYSTEM_HEADER_DIR=$build_system_header_dir
+ SYSTEM_HEADER_DIR=$BUILD_SYSTEM_HEADER_DIR
case $target in
*-*-mingw*)
if test "x$with_head
Re: [PATCH] Fix fixincludes for canadian cross builds
Hi Bernd, On 14 April 2017 at 06:18, Bernd Edlinger wrote: > On 04/12/17 17:58, Yvan Roux wrote: >> Hi, >> >> On 20 February 2017 at 18:53, Bruce Korb wrote: >>> On 02/18/17 01:01, Bernd Edlinger wrote: On 02/18/17 00:37, Bruce Korb wrote: > On 02/06/17 10:44, Bernd Edlinger wrote: >> I tested this change with different arm-linux-gnueabihf cross >> compilers, and verified that mkheaders still works on the host system. >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >> Is it OK for trunk? > > As long as you certify that this is correct for all systems we care about: > > +BUILD_SYSTEM_HEADER_DIR = ` > +echo $(CROSS_SYSTEM_HEADER_DIR) | \ > +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` > > that is pretty obtuse sed-speak to me. I suggest a comment > explaining what sed is supposed to be doing. What should > "$(CROSS_SYSTEM_HEADER_DIR)" look like? > I took it just from a few lines above, so I thought that comment would sufficiently explain the syntax: >>> >>> I confess, I didn't pull a new copy of gcc, sorry. >>> So it looks good to me. >> >> >> We just noticed that this patch brakes canadian cross builds when >> configured with --with-build-sysroot, since headers are searched into >> the target sysroot instead of the one specified for builds. >> >> Maybe there's a cleaner way to fix this and avoid the duplication but >> I didn't find another to test if --with-build-sysroot is used. The >> attached patch fixes the issue. Tested with a Full canadian cross >> build for i686-w64-mingw32 host and arm-linux-gnueabihf. >> >> Thanks >> Yvan >> >> 2017-04-12 Yvan Roux >> >>* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR >>when configured with --with-build-sysroot. >> > > Oops, sorry for the breakage... > > However I think the patch simply restores the previous behavior, because > ifdef SYSROOT_CFLAGS_FOR_TARGET is always true, even if it's empty, > but it does still not work correctly. hmm, according to Makefile manual ifdef VAR is true if VAR is non-empty, but maybe SYSROOT_CFLAGS_FOR_TARGET is set to an empty string when --with-build-sysroot is not used, sorry for not having tested this case :/ > I tried to build a cross with your patch and a --with-build-sysroot > but the target compiler does fix the wrong includes for me: > > ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross > --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf > --enable-languages=c,c++,ada,fortran --with-arch=armv7-a > --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard > --with-build-sysroot=/home/ed/gnu/arm-linux-gnueabihf-3 > => > Fixing headers into > /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed for > arm-unknown-linux-gnueabihf target > Forbidden identifiers: linux unix > Finding directories and links to directories > Searching /usr/include/. > Searching /usr/include/./c++/4.8.4 > Searching /usr/include/./numpy > Searching /usr/include/./python2.7/numpy > Making symbolic directory links > Fixing directory /usr/include into > /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed > > but it should fix headers in .../arm-linux-gnueabihf-3/usr/include > > I think it would work if I use --with-sysroot together with > --with-build-sysroot in the config above, but why should the > target compiler use --with-sysroot ? > There is no need for that on the target, just the cross-compiler > might need to support that. Ah yes, sorry ! we use both together, my understanding was that --with-build-sysroot only makes sense we --with-sysroot is used. > I tried to fix some possible combinations of --with-sysroot/ > --with-build-sysroot, and moved the logic to the configure > script. When I did that I noticed also some more glitches > when grabbing the TARGET_GLIBC_MAJOR/MINOR defines from sysroot > files. > > This updated patch seems to work for me, could you give it a try? The patch looks good to me, and works fine. Thanks a lot Bernd. Cheers, Yvan
Re: [PATCH] Fix fixincludes for canadian cross builds
Hi Yvan, On 04/14/17 10:24, Yvan Roux wrote: > Hi Bernd, > > On 14 April 2017 at 06:18, Bernd Edlinger wrote: >> On 04/12/17 17:58, Yvan Roux wrote: >>> Hi, >>> >>> On 20 February 2017 at 18:53, Bruce Korb wrote: On 02/18/17 01:01, Bernd Edlinger wrote: > On 02/18/17 00:37, Bruce Korb wrote: >> On 02/06/17 10:44, Bernd Edlinger wrote: >>> I tested this change with different arm-linux-gnueabihf cross >>> compilers, and verified that mkheaders still works on the host system. >>> >>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>> Is it OK for trunk? >> >> As long as you certify that this is correct for all systems we care >> about: >> >> +BUILD_SYSTEM_HEADER_DIR = ` >> +echo $(CROSS_SYSTEM_HEADER_DIR) | \ >> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` >> >> that is pretty obtuse sed-speak to me. I suggest a comment >> explaining what sed is supposed to be doing. What should >> "$(CROSS_SYSTEM_HEADER_DIR)" look like? >> > > I took it just from a few lines above, so I thought that comment would > sufficiently explain the syntax: I confess, I didn't pull a new copy of gcc, sorry. So it looks good to me. >>> >>> >>> We just noticed that this patch brakes canadian cross builds when >>> configured with --with-build-sysroot, since headers are searched into >>> the target sysroot instead of the one specified for builds. >>> >>> Maybe there's a cleaner way to fix this and avoid the duplication but >>> I didn't find another to test if --with-build-sysroot is used. The >>> attached patch fixes the issue. Tested with a Full canadian cross >>> build for i686-w64-mingw32 host and arm-linux-gnueabihf. >>> >>> Thanks >>> Yvan >>> >>> 2017-04-12 Yvan Roux >>> >>>* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR >>>when configured with --with-build-sysroot. >>> >> >> Oops, sorry for the breakage... >> >> However I think the patch simply restores the previous behavior, because >> ifdef SYSROOT_CFLAGS_FOR_TARGET is always true, even if it's empty, >> but it does still not work correctly. > > hmm, according to Makefile manual ifdef VAR is true if VAR is > non-empty, but maybe SYSROOT_CFLAGS_FOR_TARGET is set to an empty > string when --with-build-sysroot is not used, sorry for not having > tested this case :/ > Yes, interesting point, the reason must have been somewhere else then. Actually the "else ifdef" syntax appears to be working to my surprise: I use gnu make 3.81 here. But the manual says "else" has to be on a line of it's own, and I have never seen that syntax being used before. >> I tried to build a cross with your patch and a --with-build-sysroot >> but the target compiler does fix the wrong includes for me: >> >> ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross >> --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf >> --enable-languages=c,c++,ada,fortran --with-arch=armv7-a >> --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard >> --with-build-sysroot=/home/ed/gnu/arm-linux-gnueabihf-3 >> => >> Fixing headers into >> /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed for >> arm-unknown-linux-gnueabihf target >> Forbidden identifiers: linux unix >> Finding directories and links to directories >> Searching /usr/include/. >> Searching /usr/include/./c++/4.8.4 >> Searching /usr/include/./numpy >> Searching /usr/include/./python2.7/numpy >> Making symbolic directory links >> Fixing directory /usr/include into >> /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed >> >> but it should fix headers in .../arm-linux-gnueabihf-3/usr/include >> >> I think it would work if I use --with-sysroot together with >> --with-build-sysroot in the config above, but why should the >> target compiler use --with-sysroot ? >> There is no need for that on the target, just the cross-compiler >> might need to support that. > > Ah yes, sorry ! we use both together, my understanding was that > --with-build-sysroot only makes sense we --with-sysroot is used. > No problem, there are certainly many situations when that is true. >> I tried to fix some possible combinations of --with-sysroot/ >> --with-build-sysroot, and moved the logic to the configure >> script. When I did that I noticed also some more glitches >> when grabbing the TARGET_GLIBC_MAJOR/MINOR defines from sysroot >> files. >> >> This updated patch seems to work for me, could you give it a try? > > The patch looks good to me, and works fine. > > Thanks a lot Bernd. > > Cheers, > Yvan > Hi RMs: I am sorry that this happened so close to the imminent gcc-7 release date. To my best knowledge it would be fine to apply this update patch on the trunk: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00649.html But if you decide otherwise, I am also ready to revert my original commit: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=245613 Thanks Bernd.
Re: [PATCH] Fix fixincludes for canadian cross builds
On 14 April 2017 at 12:29, Bernd Edlinger wrote: > Hi Yvan, > > On 04/14/17 10:24, Yvan Roux wrote: >> Hi Bernd, >> >> On 14 April 2017 at 06:18, Bernd Edlinger wrote: >>> On 04/12/17 17:58, Yvan Roux wrote: Hi, On 20 February 2017 at 18:53, Bruce Korb wrote: > On 02/18/17 01:01, Bernd Edlinger wrote: >> On 02/18/17 00:37, Bruce Korb wrote: >>> On 02/06/17 10:44, Bernd Edlinger wrote: I tested this change with different arm-linux-gnueabihf cross compilers, and verified that mkheaders still works on the host system. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? >>> >>> As long as you certify that this is correct for all systems we care >>> about: >>> >>> +BUILD_SYSTEM_HEADER_DIR = ` >>> +echo $(CROSS_SYSTEM_HEADER_DIR) | \ >>> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` >>> >>> that is pretty obtuse sed-speak to me. I suggest a comment >>> explaining what sed is supposed to be doing. What should >>> "$(CROSS_SYSTEM_HEADER_DIR)" look like? >>> >> >> I took it just from a few lines above, so I thought that comment would >> sufficiently explain the syntax: > > I confess, I didn't pull a new copy of gcc, sorry. > So it looks good to me. We just noticed that this patch brakes canadian cross builds when configured with --with-build-sysroot, since headers are searched into the target sysroot instead of the one specified for builds. Maybe there's a cleaner way to fix this and avoid the duplication but I didn't find another to test if --with-build-sysroot is used. The attached patch fixes the issue. Tested with a Full canadian cross build for i686-w64-mingw32 host and arm-linux-gnueabihf. Thanks Yvan 2017-04-12 Yvan Roux * Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR when configured with --with-build-sysroot. >>> >>> Oops, sorry for the breakage... >>> >>> However I think the patch simply restores the previous behavior, because >>> ifdef SYSROOT_CFLAGS_FOR_TARGET is always true, even if it's empty, >>> but it does still not work correctly. >> >> hmm, according to Makefile manual ifdef VAR is true if VAR is >> non-empty, but maybe SYSROOT_CFLAGS_FOR_TARGET is set to an empty >> string when --with-build-sysroot is not used, sorry for not having >> tested this case :/ >> > > Yes, interesting point, the reason must have been somewhere else then. > Actually the "else ifdef" syntax appears to be working to my surprise: > I use gnu make 3.81 here. But the manual says "else" has to be on a > line of it's own, and I have never seen that syntax being used before. Oh, maybe the syntax was changed, I use gnu make 4.2 and the syntax for complex conditional in the manual (https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax) contains: conditional-directive-one text-if-one-is-true else conditional-directive-two ... I made more tests, and when configured without --with-build-sysroot, SYSROOT_CFLAGS_FOR_TARGET really is empty in gcc/Makefile, so I don't understand why my patch didn't work... But anyway, your version is better than mine ;) >>> I tried to build a cross with your patch and a --with-build-sysroot >>> but the target compiler does fix the wrong includes for me: >>> >>> ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross >>> --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf >>> --enable-languages=c,c++,ada,fortran --with-arch=armv7-a >>> --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard >>> --with-build-sysroot=/home/ed/gnu/arm-linux-gnueabihf-3 >>> => >>> Fixing headers into >>> /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed for >>> arm-unknown-linux-gnueabihf target >>> Forbidden identifiers: linux unix >>> Finding directories and links to directories >>> Searching /usr/include/. >>> Searching /usr/include/./c++/4.8.4 >>> Searching /usr/include/./numpy >>> Searching /usr/include/./python2.7/numpy >>> Making symbolic directory links >>> Fixing directory /usr/include into >>> /home/ed/gnu/gcc-build-arm-linux-gnueabihf-2/gcc/include-fixed >>> >>> but it should fix headers in .../arm-linux-gnueabihf-3/usr/include >>> >>> I think it would work if I use --with-sysroot together with >>> --with-build-sysroot in the config above, but why should the >>> target compiler use --with-sysroot ? >>> There is no need for that on the target, just the cross-compiler >>> might need to support that. >> >> Ah yes, sorry ! we use both together, my understanding was that >> --with-build-sysroot only makes sense we --with-sysroot is used. >> > > No problem, there are certainly many situations when that is true. > >>> I tried to fix some possible combinations of --with-sysroot/ >>> --with-build-sysroot, and moved the logic to the configure >>> script. Wh
Re: [PATCH] Fix fixincludes for canadian cross builds
On 04/14/17 12:29, Bernd Edlinger wrote:
> Hi RMs:
>
> I am sorry that this happened so close to the imminent gcc-7 release
> date.
>
> To my best knowledge it would be fine to apply this update patch on the
> trunk: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00649.html
>
> But if you decide otherwise, I am also ready to revert my original
> commit: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=245613
>
>
> Thanks
> Bernd.
Aehm, Sorry.
I just realized that the updated patch did still not yet work correctly
in all possible configurations...
I think this part of the configure.ac needs some more rework,
but that is probably not the right time for it.
Therefore I reverted r245613 for now.
I will post an updated patch at a later time.
Thanks
Bernd.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (Revision 246978)
+++ gcc/ChangeLog (Revision 246979)
@@ -1,3 +1,11 @@
+2017-04-18 Bernd Edlinger
+
+ Revert:
+ 2017-02-20 Bernd Edlinger
+ * Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
+ (LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use BUILD_SYSTEM_HEADER_DIR
+ instead of SYSTEM_HEADER_DIR.
+
2017-04-18 Jeff Law
PR middle-end/80422
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (Revision 246978)
+++ gcc/Makefile.in (Revision 246979)
@@ -517,18 +517,11 @@
# macro is also used in a double-quoted context.
SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e
's,[^/]*/\.\.\/,,' -e ta`
-# Path to the system headers on the build machine
-ifeq ($(build),$(host))
-BUILD_SYSTEM_HEADER_DIR = $(SYSTEM_HEADER_DIR)
-else
-BUILD_SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a
-e 's,[^/]*/\.\.\/,,' -e ta`
-endif
-
# Control whether to run fixincludes.
STMP_FIXINC = @STMP_FIXINC@
# Test to see whether exists in the system header files.
-LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]
+LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
# Directory for prefix to system directories, for
# each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
@@ -579,7 +572,7 @@
else
ifeq ($(enable_multiarch),auto)
# SYSTEM_HEADER_DIR is makefile syntax, cannot be evaluated in
configure.ac
-if_multiarch = $(if $(wildcard $(shell echo
$(BUILD_SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
+if_multiarch = $(if $(wildcard $(shell echo
$(SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
else
if_multiarch =
endif
@@ -2999,11 +2992,11 @@
sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed$${multi_dir}; \
- if ! $(inhibit_libc) && test ! -d ${BUILD_SYSTEM_HEADER_DIR}; then \
+ if ! $(inhibit_libc) && test ! -d ${SYSTEM_HEADER_DIR}; then \
echo The directory that should contain system headers does not
exist: >&2 ; \
- echo " ${BUILD_SYSTEM_HEADER_DIR}" >&2 ; \
+ echo " ${SYSTEM_HEADER_DIR}" >&2 ; \
tooldir_sysinc=`echo "${gcc_tooldir}/sys-include" | sed -e :a
-e "s,[^/]*/\.\.\/,," -e ta`; \
- if test "x${BUILD_SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
+ if test "x${SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
then sleep 1; else exit 1; fi; \
fi; \
$(mkinstalldirs) $${fix_dir}; \
@@ -3014,7 +3007,7 @@
export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
cd $(build_objdir)/fixincludes && \
$(SHELL) ./fixinc.sh "$${gcc_dir}/$${fix_dir}" \
- $(BUILD_SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
+ $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
rm -f $${fix_dir}/syslimits.h; \
if [ -f $${fix_dir}/limits.h ]; then \
mv $${fix_dir}/limits.h $${fix_dir}/syslimits.h; \
Re: [PATCH] Fix fixincludes for canadian cross builds
On 18 April 2017 at 20:17, Bernd Edlinger wrote:
> On 04/14/17 12:29, Bernd Edlinger wrote:
>> Hi RMs:
>>
>> I am sorry that this happened so close to the imminent gcc-7 release
>> date.
>>
>> To my best knowledge it would be fine to apply this update patch on the
>> trunk: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00649.html
>>
>> But if you decide otherwise, I am also ready to revert my original
>> commit: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=245613
>>
>>
>> Thanks
>> Bernd.
>
> Aehm, Sorry.
>
> I just realized that the updated patch did still not yet work correctly
> in all possible configurations...
>
> I think this part of the configure.ac needs some more rework,
> but that is probably not the right time for it.
>
> Therefore I reverted r245613 for now.
>
>
> I will post an updated patch at a later time.
Thanks Bernd, let me know if you want me to try your patch in with our
configurations.
>
> Thanks
> Bernd.
>
>
> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog (Revision 246978)
> +++ gcc/ChangeLog (Revision 246979)
> @@ -1,3 +1,11 @@
> +2017-04-18 Bernd Edlinger
> +
> + Revert:
> + 2017-02-20 Bernd Edlinger
> + * Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
> + (LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use
> BUILD_SYSTEM_HEADER_DIR
> + instead of SYSTEM_HEADER_DIR.
> +
> 2017-04-18 Jeff Law
>
> PR middle-end/80422
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in (Revision 246978)
> +++ gcc/Makefile.in (Revision 246979)
> @@ -517,18 +517,11 @@
> # macro is also used in a double-quoted context.
> SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e
> 's,[^/]*/\.\.\/,,' -e ta`
>
> -# Path to the system headers on the build machine
> -ifeq ($(build),$(host))
> -BUILD_SYSTEM_HEADER_DIR = $(SYSTEM_HEADER_DIR)
> -else
> -BUILD_SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a
> -e 's,[^/]*/\.\.\/,,' -e ta`
> -endif
> -
> # Control whether to run fixincludes.
> STMP_FIXINC = @STMP_FIXINC@
>
> # Test to see whether exists in the system header files.
> -LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]
> +LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
>
> # Directory for prefix to system directories, for
> # each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc.
> @@ -579,7 +572,7 @@
> else
> ifeq ($(enable_multiarch),auto)
> # SYSTEM_HEADER_DIR is makefile syntax, cannot be evaluated in
> configure.ac
> -if_multiarch = $(if $(wildcard $(shell echo
> $(BUILD_SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
> +if_multiarch = $(if $(wildcard $(shell echo
> $(SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
> else
> if_multiarch =
> endif
> @@ -2999,11 +2992,11 @@
> sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
> multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
> fix_dir=include-fixed$${multi_dir}; \
> - if ! $(inhibit_libc) && test ! -d ${BUILD_SYSTEM_HEADER_DIR};
> then \
> + if ! $(inhibit_libc) && test ! -d ${SYSTEM_HEADER_DIR}; then \
> echo The directory that should contain system headers does not
> exist: >&2 ; \
> - echo " ${BUILD_SYSTEM_HEADER_DIR}" >&2 ; \
> + echo " ${SYSTEM_HEADER_DIR}" >&2 ; \
> tooldir_sysinc=`echo "${gcc_tooldir}/sys-include" | sed -e :a
> -e "s,[^/]*/\.\.\/,," -e ta`; \
> - if test "x${BUILD_SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
> + if test "x${SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
> then sleep 1; else exit 1; fi; \
> fi; \
> $(mkinstalldirs) $${fix_dir}; \
> @@ -3014,7 +3007,7 @@
> export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
> cd $(build_objdir)/fixincludes && \
> $(SHELL) ./fixinc.sh "$${gcc_dir}/$${fix_dir}" \
> - $(BUILD_SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
> + $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
> rm -f $${fix_dir}/syslimits.h; \
> if [ -f $${fix_dir}/limits.h ]; then \
> mv $${fix_dir}/limits.h $${fix_dir}/syslimits.h; \
[PATCH] Fix fixincludes for canadian cross builds - next try
Hi!
This is my new attempt to clean up the different cross compiler
configurations. It turned out to be a very complicated matter,
so I thought it would be better to postpone it to the stage1.
In a canadian cross compiler setup we have a different header dir path
for use in the build and later on the target, which is written to
install-tools/mkheaders.conf, so I propose to export SYSTEM_HEADER_DIR
and BUILD_SYSTEM_HEADER_DIR from configure.ac to be used in Makefile.in.
I also removed unnecessary handling of --with-headers, because
the headers are copied to sys-include and thus it is not necessary to
use the original path here.
If --with-sysroot or --with-build-sysroot is used the SYSTEM_HEADER_DIR
or BUILD_SYSTEM_HEADER_DIR contain $${sysroot_headers_suffix},
which is normally an empty string, but on mips it may be something
like "mips-r2" which gets appended to the sysroot for use of fixincludes
but "target_header_dir" which is used in configure to find things like
the GLIBC version it is not used. I assume that that either does
not create problems and is silently ignored, or that people have a
work around, my patch should not change that, however I have not been
able to setup a sysroot for mips*-img-linux* or mips*-mti-linux* which
seem to be the only targets where this might make a difference.
I have tested all different combinations of --with-sysroot /
--with-build-sysroot. Even a native build with --with-sysroot works.
Except go of course: cross-builds are a no-go area for the go language
in general ;)
As before I would appreciate your kind help with testing the many
different build setups.
So far I have tested native x86_64-pc-linux-gnu and arm-linux-gnueabihf
cross build configurations. And everything looks sane.
Is it OK for trunk?
Thanks
Bernd.
2017-04-18 Bernd Edlinger
* configure.ac (SYSTEM_HEADER_DIR, BUILD_SYSTEM_HEADER_DIR,
target_header_dir): Set correctly.
* configure: Regenerated.
* Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
(LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use BUILD_SYSTEM_HEADER_DIR
instead of SYSTEM_HEADER_DIR.
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 246979)
+++ gcc/configure.ac (working copy)
@@ -1998,41 +1998,29 @@ done
CROSS= AC_SUBST(CROSS)
ALL=all.internalAC_SUBST(ALL)
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)' AC_SUBST(SYSTEM_HEADER_DIR)
+BUILD_SYSTEM_HEADER_DIR=$SYSTEM_HEADER_DIR AC_SUBST(BUILD_SYSTEM_HEADER_DIR)
-if test "x$with_build_sysroot" != x; then
- build_system_header_dir=$with_build_sysroot'$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
-else
- # This value is used, even on a native system, because
- # CROSS_SYSTEM_HEADER_DIR is just
- # $(TARGET_SYSTEM_ROOT)$(NATIVE_SYSTEM_HEADER_DIR).
- build_system_header_dir='$(CROSS_SYSTEM_HEADER_DIR)'
-fi
+if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x ||
+ test x$build != x$host || test "x$with_build_sysroot" != x; then
+ if test "x$with_build_sysroot" != x; then
+BUILD_SYSTEM_HEADER_DIR=$with_build_sysroot'$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+ else
+BUILD_SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)'
+ fi
-if test x$host != x$target
-then
- CROSS="-DCROSS_DIRECTORY_STRUCTURE"
- ALL=all.cross
- SYSTEM_HEADER_DIR=$build_system_header_dir
- case $target in
- *-*-mingw*)
- if test "x$with_headers" = x; then
-with_headers=yes
- fi
- ;;
- *)
- ;;
- esac
-elif test "x$TARGET_SYSTEM_ROOT" != x; then
-SYSTEM_HEADER_DIR=$build_system_header_dir
-fi
+ if test x$host != x$target
+ then
+CROSS="-DCROSS_DIRECTORY_STRUCTURE"
+ALL=all.cross
+SYSTEM_HEADER_DIR=$BUILD_SYSTEM_HEADER_DIR
+ elif test "x$TARGET_SYSTEM_ROOT" != x; then
+SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)'
+ fi
-if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
- if test "x$with_headers" != x && test "x$with_headers" != xyes; then
-target_header_dir=$with_headers
+ if test "x$with_build_sysroot" != "x"; then
+target_header_dir="${with_build_sysroot}${native_system_header_dir}"
elif test "x$with_sysroot" = x; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
- elif test "x$with_build_sysroot" != "x"; then
-target_header_dir="${with_build_sysroot}${native_system_header_dir}"
elif test "x$with_sysroot" = xyes; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
else
Index: gcc/configure
===
--- gcc/configure (revision 246979)
+++ gcc/configure (working copy)
@@ -719,6 +719,7 @@ BUILD_CFLAGS
CXX_FOR_BUILD
CC_FOR_BUILD
inhibit_libc
+BUILD_SYSTEM_HEADER_DIR
SYSTEM_HEADER_DIR
ALL
CROSS
@@ -12214,41 +12215,29 @@ done
CROSS=
ALL=all.internal
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
+BUILD_SYSTEM_HEADER_DIR=$SYSTEM
RE: [PATCH] Fix fixincludes for canadian cross builds - next try
Bernd Edlinger writes:
> This is my new attempt to clean up the different cross compiler
> configurations. It turned out to be a very complicated matter,
> so I thought it would be better to postpone it to the stage1.
>
> In a canadian cross compiler setup we have a different header dir path
> for use in the build and later on the target, which is written to
> install-tools/mkheaders.conf, so I propose to export SYSTEM_HEADER_DIR
> and BUILD_SYSTEM_HEADER_DIR from configure.ac to be used in Makefile.in.
>
> I also removed unnecessary handling of --with-headers, because
> the headers are copied to sys-include and thus it is not necessary to
> use the original path here.
>
> If --with-sysroot or --with-build-sysroot is used the SYSTEM_HEADER_DIR
> or BUILD_SYSTEM_HEADER_DIR contain $${sysroot_headers_suffix},
> which is normally an empty string, but on mips it may be something
> like "mips-r2" which gets appended to the sysroot for use of fixincludes
> but "target_header_dir" which is used in configure to find things like
> the GLIBC version it is not used. I assume that that either does
> not create problems and is silently ignored, or that people have a
> work around, my patch should not change that, however I have not been
> able to setup a sysroot for mips*-img-linux* or mips*-mti-linux* which
> seem to be the only targets where this might make a difference.
I'll try to test this out for you with MIPS. I have changes I want to make
to further improve the cross builds for the mti and img vendor builds so
if there is a bit of fallout I could deal with it then.
Matthew
Re: [PATCH] Fix fixincludes for canadian cross builds - next try
Hi Bernd,
On 20 April 2017 at 21:11, Bernd Edlinger wrote:
> Hi!
>
> This is my new attempt to clean up the different cross compiler
> configurations. It turned out to be a very complicated matter,
> so I thought it would be better to postpone it to the stage1.
>
> In a canadian cross compiler setup we have a different header dir path
> for use in the build and later on the target, which is written to
> install-tools/mkheaders.conf, so I propose to export SYSTEM_HEADER_DIR
> and BUILD_SYSTEM_HEADER_DIR from configure.ac to be used in Makefile.in.
>
> I also removed unnecessary handling of --with-headers, because
> the headers are copied to sys-include and thus it is not necessary to
> use the original path here.
>
> If --with-sysroot or --with-build-sysroot is used the SYSTEM_HEADER_DIR
> or BUILD_SYSTEM_HEADER_DIR contain $${sysroot_headers_suffix},
> which is normally an empty string, but on mips it may be something
> like "mips-r2" which gets appended to the sysroot for use of fixincludes
> but "target_header_dir" which is used in configure to find things like
> the GLIBC version it is not used. I assume that that either does
> not create problems and is silently ignored, or that people have a
> work around, my patch should not change that, however I have not been
> able to setup a sysroot for mips*-img-linux* or mips*-mti-linux* which
> seem to be the only targets where this might make a difference.
>
> I have tested all different combinations of --with-sysroot /
> --with-build-sysroot. Even a native build with --with-sysroot works.
> Except go of course: cross-builds are a no-go area for the go language
> in general ;)
>
> As before I would appreciate your kind help with testing the many
> different build setups.
Canadian cross build for i686-w64-mingw32 host and arm-linux-gnueabihf
target configured with both --with-sysroot and --with-build-sysroot is
okay (with SYSTEM_HEADER_DIR, BUILD_SYSTEM_HEADER_DIR and
TARGET_SYSTEM_ROOT containing the good paths).
>
> So far I have tested native x86_64-pc-linux-gnu and arm-linux-gnueabihf
> cross build configurations. And everything looks sane.
>
> Is it OK for trunk?
>
>
> Thanks
> Bernd.
Re: [PATCH] Fix fixincludes for canadian cross builds - next try
On 04/20/2017 01:11 PM, Bernd Edlinger wrote:
Hi!
This is my new attempt to clean up the different cross compiler
configurations. It turned out to be a very complicated matter,
so I thought it would be better to postpone it to the stage1.
In a canadian cross compiler setup we have a different header dir path
for use in the build and later on the target, which is written to
install-tools/mkheaders.conf, so I propose to export SYSTEM_HEADER_DIR
and BUILD_SYSTEM_HEADER_DIR from configure.ac to be used in Makefile.in.
I also removed unnecessary handling of --with-headers, because
the headers are copied to sys-include and thus it is not necessary to
use the original path here.
If --with-sysroot or --with-build-sysroot is used the SYSTEM_HEADER_DIR
or BUILD_SYSTEM_HEADER_DIR contain $${sysroot_headers_suffix},
which is normally an empty string, but on mips it may be something
like "mips-r2" which gets appended to the sysroot for use of fixincludes
but "target_header_dir" which is used in configure to find things like
the GLIBC version it is not used. I assume that that either does
not create problems and is silently ignored, or that people have a
work around, my patch should not change that, however I have not been
able to setup a sysroot for mips*-img-linux* or mips*-mti-linux* which
seem to be the only targets where this might make a difference.
I have tested all different combinations of --with-sysroot /
--with-build-sysroot. Even a native build with --with-sysroot works.
Except go of course: cross-builds are a no-go area for the go language
in general;)
As before I would appreciate your kind help with testing the many
different build setups.
So far I have tested native x86_64-pc-linux-gnu and arm-linux-gnueabihf
cross build configurations. And everything looks sane.
Is it OK for trunk?
Thanks
Bernd.
fixinc.diff
2017-04-18 Bernd Edlinger
* configure.ac (SYSTEM_HEADER_DIR, BUILD_SYSTEM_HEADER_DIR,
target_header_dir): Set correctly.
* configure: Regenerated.
* Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
(LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use BUILD_SYSTEM_HEADER_DIR
instead of SYSTEM_HEADER_DIR.
OK. Please watch for fallout. I'm not entirely sure mingw is working
right now, but they're often affected by this stuff.
jeff
