Hi Yvan, On 04/14/17 10:24, Yvan Roux wrote: > 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 :/ >
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.
