linux-libc-headers-native, gcc-cross issue

linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

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.

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.

However, I think this needs a more structural solution.
Suggestions are appreciated.

Frans.

PS: it might also be that other files suffer from this, but until now
I only had problems with gcc-cross

Re: linux-libc-headers-native, gcc-cross issue

[Khem Raj]

On Sun, Jun 20, 2010 at 1:51 PM, Frans Meulenbroeks
<fransmeulenbroeks@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.


>
> 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

2010/6/21 Khem Raj <raj.khem@gmail.com>:
> On Sun, Jun 20, 2010 at 1:51 PM, Frans Meulenbroeks
> <fransmeulenbroeks@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.
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@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: linux-libc-headers-native, gcc-cross issue

[Khem Raj]

On Mon, Jun 21, 2010 at 6:01 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/6/21 Khem Raj <raj.khem@gmail.com>:
>> On Sun, Jun 20, 2010 at 1:51 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@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@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

2010/6/21 Khem Raj <raj.khem@gmail.com>:
> On Mon, Jun 21, 2010 at 6:01 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/6/21 Khem Raj <raj.khem@gmail.com>:
>>> On Sun, Jun 20, 2010 at 1:51 PM, Frans Meulenbroeks
>>> <fransmeulenbroeks@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@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: linux-libc-headers-native, gcc-cross issue

[Tom Rini]

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

What DISTRO/MACHINE are you using?

-- 
Tom Rini
Mentor Graphics Corporation

Re: linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

2010/6/21 Tom Rini <tom_rini@mentor.com>:
> Frans Meulenbroeks 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
>
> What DISTRO/MACHINE are you using?

DISTRO is angstrom-2008.1, MACHINE is NEEK; this one is NIOS2 based
and not committed yet.
From examining the gcc-cross dir I suspect some other archtectures
will also be vulnerable to this (as they also have a linux-unwind.h
which includes signal.h to get sigcontext).
The following architectures have a sigcontext struct in their gcc/config dir:

gcc-cross-4.1.2-r23.1/gcc-4.1.2/gcc/config> grep -r sigcontext .
./sh/linux-unwind.h:  struct sigcontext *sc;
./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
&rt_->uc.uc_mcontext;
./sh/linux-unwind.h:  struct sigcontext *sc;
./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
&rt_->uc.uc_mcontext;
./alpha/linux-unwind.h:  struct sigcontext *sc;
./i386/linux-unwind.h:  struct sigcontext *sc;
./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
&uc_->uc_mcontext;
./i386/linux-unwind.h:  struct sigcontext *sc;
./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
&rt_->uc.uc_mcontext;
./mips/linux-unwind.h:    struct sigcontext uc_mcontext;
./mips/linux-unwind.h:  struct sigcontext *sc;
./mips/linux-unwind.h:	struct sigcontext sigctx;
./mips/linux-unwind.h:  /* On o32 Linux, the register save slots in
the sigcontext are
./ia64/linux-unwind.h:/* This works only for glibc-2.3 and later,
because sigcontext is different
./ia64/linux-unwind.h:	struct sigcontext *sc;
./ia64/linux-unwind.h:      struct sigcontext *sc = frame_->sc;
./ia64/linux-unwind.h:	 in the sigcontext but leaves them intact, so there's no
./ia64/linux-unwind.h:	struct sigcontext *sc;
./ia64/linux-unwind.h:      struct sigcontext *sc = frame->sc;
./ia64/linux-unwind.h:	 in the sigcontext but leaves them intact, so there's no
./pa/linux-unwind.h:   tell us how to locate the sigcontext structure.
./pa/linux-unwind.h:  struct sigcontext *sc;
./nios2/linux-unwind.h:	struct sigcontext ctx;

The last one (nios2) is not committed yet. i386 is probably not
vulnerable (at least not on a i386 host) and maybe the same holds for
ia64 (less sure about that).
That leaves as problematic structures: sh, alpha, mips, pa, nios2
arm does not seem to be affected.
Guess the fact that only less popular machines are affected is the
reason this did not surface earlier.

Frans.
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: linux-libc-headers-native, gcc-cross issue

[Khem Raj]

On (21/06/10 21:27), Frans Meulenbroeks wrote:
> 2010/6/21 Tom Rini <tom_rini@mentor.com>:
> > Frans Meulenbroeks 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
> >
> > What DISTRO/MACHINE are you using?
> 
> DISTRO is angstrom-2008.1, MACHINE is NEEK; this one is NIOS2 based
> and not committed yet.
> From examining the gcc-cross dir I suspect some other archtectures
> will also be vulnerable to this (as they also have a linux-unwind.h
> which includes signal.h to get sigcontext).
> The following architectures have a sigcontext struct in their gcc/config dir:
> 
> gcc-cross-4.1.2-r23.1/gcc-4.1.2/gcc/config> grep -r sigcontext .
> ./sh/linux-unwind.h:  struct sigcontext *sc;
> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> &rt_->uc.uc_mcontext;
> ./sh/linux-unwind.h:  struct sigcontext *sc;
> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> &rt_->uc.uc_mcontext;
> ./alpha/linux-unwind.h:  struct sigcontext *sc;
> ./i386/linux-unwind.h:  struct sigcontext *sc;
> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> &uc_->uc_mcontext;
> ./i386/linux-unwind.h:  struct sigcontext *sc;
> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> &rt_->uc.uc_mcontext;
> ./mips/linux-unwind.h:    struct sigcontext uc_mcontext;
> ./mips/linux-unwind.h:  struct sigcontext *sc;
> ./mips/linux-unwind.h:	struct sigcontext sigctx;
> ./mips/linux-unwind.h:  /* On o32 Linux, the register save slots in
> the sigcontext are
> ./ia64/linux-unwind.h:/* This works only for glibc-2.3 and later,
> because sigcontext is different
> ./ia64/linux-unwind.h:	struct sigcontext *sc;
> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame_->sc;
> ./ia64/linux-unwind.h:	 in the sigcontext but leaves them intact, so there's no
> ./ia64/linux-unwind.h:	struct sigcontext *sc;
> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame->sc;
> ./ia64/linux-unwind.h:	 in the sigcontext but leaves them intact, so there's no
> ./pa/linux-unwind.h:   tell us how to locate the sigcontext structure.
> ./pa/linux-unwind.h:  struct sigcontext *sc;
> ./nios2/linux-unwind.h:	struct sigcontext ctx;

try to port recipes/gcc/gcc-4.2.4/sh_unwind.patch to nios. This could help
here.

-Khem

Re: linux-libc-headers-native, gcc-cross issue

[Frans Meulenbroeks]

2010/6/21 Khem Raj <raj.khem@gmail.com>:
> On (21/06/10 21:27), Frans Meulenbroeks wrote:
>> 2010/6/21 Tom Rini <tom_rini@mentor.com>:
>> > Frans Meulenbroeks 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
>> >
>> > What DISTRO/MACHINE are you using?
>>
>> DISTRO is angstrom-2008.1, MACHINE is NEEK; this one is NIOS2 based
>> and not committed yet.
>> From examining the gcc-cross dir I suspect some other archtectures
>> will also be vulnerable to this (as they also have a linux-unwind.h
>> which includes signal.h to get sigcontext).
>> The following architectures have a sigcontext struct in their gcc/config dir:
>>
>> gcc-cross-4.1.2-r23.1/gcc-4.1.2/gcc/config> grep -r sigcontext .
>> ./sh/linux-unwind.h:  struct sigcontext *sc;
>> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
>> &rt_->uc.uc_mcontext;
>> ./sh/linux-unwind.h:  struct sigcontext *sc;
>> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
>> &rt_->uc.uc_mcontext;
>> ./alpha/linux-unwind.h:  struct sigcontext *sc;
>> ./i386/linux-unwind.h:  struct sigcontext *sc;
>> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
>> &uc_->uc_mcontext;
>> ./i386/linux-unwind.h:  struct sigcontext *sc;
>> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
>> &rt_->uc.uc_mcontext;
>> ./mips/linux-unwind.h:    struct sigcontext uc_mcontext;
>> ./mips/linux-unwind.h:  struct sigcontext *sc;
>> ./mips/linux-unwind.h:        struct sigcontext sigctx;
>> ./mips/linux-unwind.h:  /* On o32 Linux, the register save slots in
>> the sigcontext are
>> ./ia64/linux-unwind.h:/* This works only for glibc-2.3 and later,
>> because sigcontext is different
>> ./ia64/linux-unwind.h:        struct sigcontext *sc;
>> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame_->sc;
>> ./ia64/linux-unwind.h:         in the sigcontext but leaves them intact, so there's no
>> ./ia64/linux-unwind.h:        struct sigcontext *sc;
>> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame->sc;
>> ./ia64/linux-unwind.h:         in the sigcontext but leaves them intact, so there's no
>> ./pa/linux-unwind.h:   tell us how to locate the sigcontext structure.
>> ./pa/linux-unwind.h:  struct sigcontext *sc;
>> ./nios2/linux-unwind.h:       struct sigcontext ctx;
>
> try to port recipes/gcc/gcc-4.2.4/sh_unwind.patch to nios. This could help
> here.
>

Will look into it. This might indeed help (actually I don't know too
much about this).
Still of course this is only a workaround. The root cause is the host
inc dir when compiling a target dir.
Thinking of it, apart from fixing the root cause (which is probably
above my capabilities), the simplest way would be just to patch the
generated Makefile and remove the offending -I
That would also solve my unistd.h problem.

Frans

Re: linux-libc-headers-native, gcc-cross issue

[Khem Raj]

On (21/06/10 21:49), Frans Meulenbroeks wrote:
> 2010/6/21 Khem Raj <raj.khem@gmail.com>:
> > On (21/06/10 21:27), Frans Meulenbroeks wrote:
> >> 2010/6/21 Tom Rini <tom_rini@mentor.com>:
> >> > Frans Meulenbroeks 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
> >> >
> >> > What DISTRO/MACHINE are you using?
> >>
> >> DISTRO is angstrom-2008.1, MACHINE is NEEK; this one is NIOS2 based
> >> and not committed yet.
> >> From examining the gcc-cross dir I suspect some other archtectures
> >> will also be vulnerable to this (as they also have a linux-unwind.h
> >> which includes signal.h to get sigcontext).
> >> The following architectures have a sigcontext struct in their gcc/config dir:
> >>
> >> gcc-cross-4.1.2-r23.1/gcc-4.1.2/gcc/config> grep -r sigcontext .
> >> ./sh/linux-unwind.h:  struct sigcontext *sc;
> >> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> >> &rt_->uc.uc_mcontext;
> >> ./sh/linux-unwind.h:  struct sigcontext *sc;
> >> ./sh/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> >> &rt_->uc.uc_mcontext;
> >> ./alpha/linux-unwind.h:  struct sigcontext *sc;
> >> ./i386/linux-unwind.h:  struct sigcontext *sc;
> >> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> >> &uc_->uc_mcontext;
> >> ./i386/linux-unwind.h:  struct sigcontext *sc;
> >> ./i386/linux-unwind.h:      sc = (struct sigcontext *) (void *)
> >> &rt_->uc.uc_mcontext;
> >> ./mips/linux-unwind.h:    struct sigcontext uc_mcontext;
> >> ./mips/linux-unwind.h:  struct sigcontext *sc;
> >> ./mips/linux-unwind.h:        struct sigcontext sigctx;
> >> ./mips/linux-unwind.h:  /* On o32 Linux, the register save slots in
> >> the sigcontext are
> >> ./ia64/linux-unwind.h:/* This works only for glibc-2.3 and later,
> >> because sigcontext is different
> >> ./ia64/linux-unwind.h:        struct sigcontext *sc;
> >> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame_->sc;
> >> ./ia64/linux-unwind.h:         in the sigcontext but leaves them intact, so there's no
> >> ./ia64/linux-unwind.h:        struct sigcontext *sc;
> >> ./ia64/linux-unwind.h:      struct sigcontext *sc = frame->sc;
> >> ./ia64/linux-unwind.h:         in the sigcontext but leaves them intact, so there's no
> >> ./pa/linux-unwind.h:   tell us how to locate the sigcontext structure.
> >> ./pa/linux-unwind.h:  struct sigcontext *sc;
> >> ./nios2/linux-unwind.h:       struct sigcontext ctx;
> >
> > try to port recipes/gcc/gcc-4.2.4/sh_unwind.patch to nios. This could help
> > here.
> >
> 
> Will look into it. This might indeed help (actually I don't know too
> much about this).
> Still of course this is only a workaround. 

no its not a workaround. such a fix is upstream in gcc for SH and MIPS

The root cause is the host
> inc dir when compiling a target dir.
> Thinking of it, apart from fixing the root cause (which is probably
> above my capabilities), 

GMPINC should not be passed when building target files. I will see if I can
cook up something.

the simplest way would be just to patch the
> generated Makefile and remove the offending -I
> That would also solve my unistd.h problem.

thats even uglier to much with generated files.

> 
> Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel