On 14 April 2017 at 12:29, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > 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.
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. 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. And sorry for not having caught it sooner. > 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.
