[oe] linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

2010/6/21 Khem Raj <raj.khem at gmail.com>:
> On Mon, Jun 21, 2010 at 6:01 AM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
>> 2010/6/21 Khem Raj <raj.khem at gmail.com>:
>>> On Sun, Jun 20, 2010 at 1:51 PM, Frans Meulenbroeks
>>> <fransmeulenbroeks at gmail.com> wrote:
>>>> Dear all,
>>>>
>>>> After the introduction of linux-libc-headers-native I've bumped into
>>>> the following issue.
>>>> linux-libc-headers-native installs unistd.h in sysroots
>>>> This causes other recipes to pick up the x86 files instead of the target ones.
>>>> I've seen this happen for both unistd.h and sigcontext.h
>>>>
>>>> One of the recipes suffering from this is gcc-cross (for some architectures).
>>>> Reason is that files are compiled with
>>>> -I/home/frans/oe/tmp_angstrom/sysroots/i686-linux/usr/include whereas
>>>> the target specific includes are added with -isystem.
>>>> This causes the -I to win.
>>>
>>> right. gcc-cross is a special case where its not building purely cross
>>> binaries but
>>> also making libraries and objects that will run on the target. This
>>> problem probaly
>>> is seen when building startup objects  (crt*.o). This path is added by
>>> gcc build
>>> machinery as a path where it finds gmp headers. I suspect that gcc build should
>>> not be passing this in the incudes when building target stuff.
>>>
>>> I think with sysroot using -isystem<target_headers> should not be needed.
>>
>> It is not the -isystem that is the problem. as stated above there is
>> an explicit -I to sysroots/i686-linux that is causing the problem.
>
> Yes and I explained also why this -I is coming into gcc compilation.
> it was a side note to remove
> the isystems although it may not solve your problem.
>

Removing -isystem alone defnitely does not solve my problem. Removing
the -I does.
Guess I misinterpreted your proposal. Not passing the dir when
compiling target specific stuff seems a good plan.
However  I have no idea how to do that (and this recipe is way too
crucial to take a risk of breaking things).

Frans

>> This dir used to be unpopulated (or maybe even non-existing), butwith
>> linux-libc-headers-native it became populated and as it got precedence
>> the dir wins.
>> I have no idea how to remove the -I dir (and also no idea if it is ok).
>>
>> The problem only occurs in .../gcc/config/${ARCH}/
>> typical issue where this happens is linux_unwind.h This includes
>> <signal.h> to get <sigcontext.h> and eventually the typedef for
>> sigcontext.
>> However sigcontext is of course archtecture specific so if one picks
>> up the wrong signal.h it does not work.
>>
>> The unistd.h problem is probably specific for the nios2 variant, in
>> which an additional system call is defined, which of course is not
>> present in the x86 unistd.h
>>
>> Frans
>>
>>>
>>>
>>>>
>>>> In the past sysroots/i686-linux/usr/include was empty, but with
>>>> linux-libc-headers-native it gets populated causing the files in there
>>>> to be used instead of the ones in the target ones.
>>>> By setting linux-libc-headers-native to ASSUME-PROVIDED and cleaning
>>>> and rebuilding TMPDIR I was able to avoid the problem.
>>>
>>> yeah this masked the problem as it has been masked till now.
>>>
>>>>
>>>> However, I think this needs a more structural solution.
>>>> Suggestions are appreciated.
>>>
>>> We should explore if passing this isystem in CFLAGS is needed at all.
>>> if not then we should remove it.
>>>
>>>>
>>>> Frans.
>>>>
>>>> PS: it might also be that other files suffer from this, but until now
>>>> I only had problems with gcc-cross
>>>
>>> could be but I doubt.
>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> Openembedded-devel at lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>