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

[Khem Raj]

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.

> 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
>