Hi Bernd, On 14 April 2017 at 06:18, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 04/12/17 17:58, Yvan Roux wrote: >> Hi, >> >> On 20 February 2017 at 18:53, Bruce Korb <bk...@gnu.org> 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 <yvan.r...@linaro.org> >> >> * 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
