[PATCH] Fix fixincludes for canadian cross builds

[Bernd Edlinger]

Hi Yvan,

On 04/14/17 10:24, Yvan Roux wrote:
> Hi Bernd,
>
> On 14 April 2017 at 06:18, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>> On 04/12/17 17:58, Yvan Roux wrote:
>>> Hi,
>>>
>>> On 20 February 2017 at 18:53, Bruce Korb <bkorb@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.roux@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.