Patchwork bash: Add fix for cross compile issues

login
register
mail settings
Submitter Richard Purdie
Date Nov. 13, 2012, 1:59 p.m.
Message ID <1352815159.24487.122.camel@ted>
Download mbox | patch
Permalink /patch/38919/
State New
Headers show

Comments

Richard Purdie - Nov. 13, 2012, 1:59 p.m.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
Chris Larson - Nov. 13, 2012, 11:42 p.m.
On Tue, Nov 13, 2012 at 6:59 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> new file mode 100644
> index 0000000..f587c34
> --- a/dev/null
> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> @@ -0,0 +1,28 @@
> +Adding @CROSS_COMPILE@ to CFLAGS_FOR_BUILD causes errors like:
> +
> +mkbuiltins.o: In function `open':
> +/usr/include/x86_64-linux-gnu/bits/fcntl2.h:54: undefined reference to
> `xopen'
> +mkbuiltins.o: In function `read':
> +/usr/include/x86_64-linux-gnu/bits/unistd.h:45: undefined reference to
> `xread'
> +collect2: ld returned 1 exit status
> +
> +when compiling on a 64 bit x86 build system for a 32 bit x86 target since
> +config.h confuses the compiler about settings. By removing the option,
> config.h
> +isn't used and the compiler stops getting confused.
> +
> +Upstream-Status: Pending
> +RP 2012/11/13
>

Relying on the target config.h to build a host tool could fail if the build
and target environments differ greatly, which is likely why mkbuiltins.c
has hardcoded defines assuming less about the host (just POSIX) based on
the CROSS_COMPILE define. I don't think removing that is the best fix,
personally.

The reason for this failure has to do with a particular set of
circumstances. A header in the bash source tree defines STRING() based on
HAVE_STRINGIZE. This define overwrites the unistd.h define of the same
macro. The unistd.h definitions of read() and open() wrap the call to the
real functions to implement FORTIFY_SOURCES, and those wrappers use
STRING() to do it. As a result, for any host that defaults to
-DFORTIFY_SOURCES, STRING() returns 'x' resulting in a concatenation rather
than an assembly level rename of the function being called.

If we add -DHAVE_STRINGIZE in the CROSS_COMPILE case, then STRING() will be
defined to something useful, and therefore the FORTIFY_SOURCES wrappers
don't get hosed.

See http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91for
an alternative fix which may be more likely to be accepted upstream.
Martin Jansa - Nov. 14, 2012, 12:30 p.m.
On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> new file mode 100644
> index 0000000..f587c34
> --- a/dev/null
> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> @@ -0,0 +1,28 @@

Are you using some special tool to generate git patches or some weird
git version?

Patches from you where you add some file usually does not apply here,
It's caused by:
--- a/dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
which usually looks like
--- /dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch

2012-11-14 13:22:27 URL:http://patchwork.openembedded.org/patch/38919/mbox/ [2833] -> "pw-am-38919.patch" [1]
Applying: bash: Add fix for cross compile issues
fatal: git apply: bad git-diff - expected /dev/null on line 7
Patch failed at 0001 bash: Add fix for cross compile issues
The copy of the patch that failed is found in:
   /OE/openembedded-core/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Cheers,
Richard Purdie - Nov. 14, 2012, 1:01 p.m.
On Tue, 2012-11-13 at 16:42 -0700, Chris Larson wrote:

> On Tue, Nov 13, 2012 at 6:59 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         Signed-off-by: Richard Purdie
>         <richard.purdie@linuxfoundation.org>
>         ---
>         diff --git
>         a/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>         b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>         new file mode 100644
>         index 0000000..f587c34
>         --- a/dev/null
>         +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>         @@ -0,0 +1,28 @@
>         +Adding @CROSS_COMPILE@ to CFLAGS_FOR_BUILD causes errors
>         like:
>         +
>         +mkbuiltins.o: In function `open':
>         +/usr/include/x86_64-linux-gnu/bits/fcntl2.h:54: undefined
>         reference to `xopen'
>         +mkbuiltins.o: In function `read':
>         +/usr/include/x86_64-linux-gnu/bits/unistd.h:45: undefined
>         reference to `xread'
>         +collect2: ld returned 1 exit status
>         +
>         +when compiling on a 64 bit x86 build system for a 32 bit x86
>         target since
>         +config.h confuses the compiler about settings. By removing
>         the option, config.h
>         +isn't used and the compiler stops getting confused.
>         +
>         +Upstream-Status: Pending
>         +RP 2012/11/13
> 
> Relying on the target config.h to build a host tool could fail if the
> build and target environments differ greatly, which is likely why
> mkbuiltins.c has hardcoded defines assuming less about the host (just
> POSIX) based on the CROSS_COMPILE define. I don't think removing that
> is the best fix, personally.

Agreed. I'd actually misread that file and thought that it was using
config.h in the CROSS_COMPILE case.

> The reason for this failure has to do with a particular set of
> circumstances. A header in the bash source tree defines STRING() based
> on HAVE_STRINGIZE. This define overwrites the unistd.h define of the
> same macro. The unistd.h definitions of read() and open() wrap the
> call to the real functions to implement FORTIFY_SOURCES, and those
> wrappers use STRING() to do it. As a result, for any host that
> defaults to -DFORTIFY_SOURCES, STRING() returns 'x' resulting in a
> concatenation rather than an assembly level rename of the function
> being called.
>
> If we add -DHAVE_STRINGIZE in the CROSS_COMPILE case, then STRING()
> will be defined to something useful, and therefore the FORTIFY_SOURCES
> wrappers don't get hosed.
>
> See http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91 for an alternative fix which may be more likely to be accepted upstream.
> 
This is better, yes. Is there a reason this is in meta-mentor and not
OE-Core? I'd really like to pull it into OE-Core...

Cheers,

Richard
Richard Purdie - Nov. 14, 2012, 1:24 p.m.
On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
> On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > new file mode 100644
> > index 0000000..f587c34
> > --- a/dev/null
> > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > @@ -0,0 +1,28 @@
> 
> Are you using some special tool to generate git patches or some weird
> git version?

Basically, the data from cgit in the web interface is broken and that is
causing this.

> Patches from you where you add some file usually does not apply here,
> It's caused by:
> --- a/dev/null
> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> which usually looks like
> --- /dev/null
> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch

Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
find/fix it?

Cheers,

Richard
Richard Purdie - Nov. 14, 2012, 1:30 p.m.
On Wed, 2012-11-14 at 13:24 +0000, Richard Purdie wrote:
> On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
> > On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
> > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > > ---
> > > diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > > new file mode 100644
> > > index 0000000..f587c34
> > > --- a/dev/null
> > > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > > @@ -0,0 +1,28 @@
> > 
> > Are you using some special tool to generate git patches or some weird
> > git version?
> 
> Basically, the data from cgit in the web interface is broken and that is
> causing this.
> 
> > Patches from you where you add some file usually does not apply here,
> > It's caused by:
> > --- a/dev/null
> > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > which usually looks like
> > --- /dev/null
> > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> 
> Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
> find/fix it?

Actually, its not hard to find:

http://hjemli.net/git/cgit/tree/ui-patch.c


In header(), the:
		htmlf("\n--- a/%s\n", path1);
		htmlf("+++ b/%s\n", path2);
needs to be conditional on is_null_sha1(sha1)/is_null_sha1(sha2) with
the alternative of:
		htmlf("\n--- /%s\n", path1);
		htmlf("+++ /%s\n", path2);
which there are a variety of ways to achieve...

Michael: Fancy fixing that on the server and sending a patch
upstream? :)

Cheers,

Richard
Martin Jansa - Nov. 14, 2012, 2:06 p.m.
On Wed, Nov 14, 2012 at 01:24:02PM +0000, Richard Purdie wrote:
> On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
> > On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
> > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > > ---
> > > diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > > new file mode 100644
> > > index 0000000..f587c34
> > > --- a/dev/null
> > > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > > @@ -0,0 +1,28 @@
> > 
> > Are you using some special tool to generate git patches or some weird
> > git version?
> 
> Basically, the data from cgit in the web interface is broken and that is
> causing this.

You're copy pasting cgit output to email when sending patches, or how is
cgit involved in your patch flow?

I'm just curious, because I usually use only git send-email or
create-pull-request script.

Cheers,

> > Patches from you where you add some file usually does not apply here,
> > It's caused by:
> > --- a/dev/null
> > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> > which usually looks like
> > --- /dev/null
> > +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> 
> Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
> find/fix it?
> 
> Cheers,
> 
> Richard
>
Chris Larson - Nov. 14, 2012, 2:08 p.m.
On Wed, Nov 14, 2012 at 6:01 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> > The reason for this failure has to do with a particular set of
> > circumstances. A header in the bash source tree defines STRING() based
> > on HAVE_STRINGIZE. This define overwrites the unistd.h define of the
> > same macro. The unistd.h definitions of read() and open() wrap the
> > call to the real functions to implement FORTIFY_SOURCES, and those
> > wrappers use STRING() to do it. As a result, for any host that
> > defaults to -DFORTIFY_SOURCES, STRING() returns 'x' resulting in a
> > concatenation rather than an assembly level rename of the function
> > being called.
> >
> > If we add -DHAVE_STRINGIZE in the CROSS_COMPILE case, then STRING()
> > will be defined to something useful, and therefore the FORTIFY_SOURCES
> > wrappers don't get hosed.
> >
> > See
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91for an alternative fix which may be more likely to be accepted upstream.
> >
> This is better, yes. Is there a reason this is in meta-mentor and not
> OE-Core? I'd really like to pull it into OE-Core...


Nope, it's just in the pending upstream pile. I'll send a patch against
oe-core to the list today if you'd like.
Richard Purdie - Nov. 14, 2012, 2:14 p.m.
On Wed, 2012-11-14 at 07:08 -0700, Chris Larson wrote:
> On Wed, Nov 14, 2012 at 6:01 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         > The reason for this failure has to do with a particular set
>         of
>         > circumstances. A header in the bash source tree defines
>         STRING() based
>         > on HAVE_STRINGIZE. This define overwrites the unistd.h
>         define of the
>         > same macro. The unistd.h definitions of read() and open()
>         wrap the
>         > call to the real functions to implement FORTIFY_SOURCES, and
>         those
>         > wrappers use STRING() to do it. As a result, for any host
>         that
>         > defaults to -DFORTIFY_SOURCES, STRING() returns 'x'
>         resulting in a
>         > concatenation rather than an assembly level rename of the
>         function
>         > being called.
>         >
>         > If we add -DHAVE_STRINGIZE in the CROSS_COMPILE case, then
>         STRING()
>         > will be defined to something useful, and therefore the
>         FORTIFY_SOURCES
>         > wrappers don't get hosed.
>         >
>         > See
>         http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91 for an alternative fix which may be more likely to be accepted upstream.
>         >
>         
>         This is better, yes. Is there a reason this is in meta-mentor
>         and not
>         OE-Core? I'd really like to pull it into OE-Core...
> 
> Nope, it's just in the pending upstream pile. I'll send a patch
> against oe-core to the list today if you'd like.

Please, I'd like to get that problem fixed.

Cheers,

Richard
Michael Halstead - Nov. 14, 2012, 7:45 p.m.
On 11/14/2012 05:30 AM, Richard Purdie wrote:
> On Wed, 2012-11-14 at 13:24 +0000, Richard Purdie wrote:
>> On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
>>> On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>> ---
>>>> diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>>> new file mode 100644
>>>> index 0000000..f587c34
>>>> --- a/dev/null
>>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>>> @@ -0,0 +1,28 @@
>>> Are you using some special tool to generate git patches or some weird
>>> git version?
>> Basically, the data from cgit in the web interface is broken and that is
>> causing this.
>>
>>> Patches from you where you add some file usually does not apply here,
>>> It's caused by:
>>> --- a/dev/null
>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>> which usually looks like
>>> --- /dev/null
>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>> Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
>> find/fix it?
> Actually, its not hard to find:
>
> http://hjemli.net/git/cgit/tree/ui-patch.c
>
>
> In header(), the:
> 		htmlf("\n--- a/%s\n", path1);
> 		htmlf("+++ b/%s\n", path2);
> needs to be conditional on is_null_sha1(sha1)/is_null_sha1(sha2) with
> the alternative of:
> 		htmlf("\n--- /%s\n", path1);
> 		htmlf("+++ /%s\n", path2);
> which there are a variety of ways to achieve...
>
> Michael: Fancy fixing that on the server and sending a patch
> upstream? :)
>
> Cheers,
>
> Richard
>
I'm happy to. I've fixed the code you've tracked down and recompiled for
git.yoctoproject.org. You can see the result at
https://git.yoctoproject.org/cgit/cgit.cgi/poky/patch/?id=ed234aca98d0867c7b32801fc63820b19cf67df9
but I am still working on fixing the shared UI for this view
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ed234aca98d0867c7b32801fc63820b19cf67df9.


Once I have both fixes I'll upgrade http://cgit.openembedded.org/ with
the new version and submit my patch upstream.
Michael Halstead - Nov. 14, 2012, 9:07 p.m.
On 11/14/2012 11:45 AM, Michael Halstead wrote:
> On 11/14/2012 05:30 AM, Richard Purdie wrote:
>> On Wed, 2012-11-14 at 13:24 +0000, Richard Purdie wrote:
>>> On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
>>>> On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
>>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>>> ---
>>>>> diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>>>> new file mode 100644
>>>>> index 0000000..f587c34
>>>>> --- a/dev/null
>>>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>>>> @@ -0,0 +1,28 @@
>>>> Are you using some special tool to generate git patches or some weird
>>>> git version?
>>> Basically, the data from cgit in the web interface is broken and that is
>>> causing this.
>>>
>>>> Patches from you where you add some file usually does not apply here,
>>>> It's caused by:
>>>> --- a/dev/null
>>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>>> which usually looks like
>>>> --- /dev/null
>>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
>>> Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
>>> find/fix it?
>> Actually, its not hard to find:
>>
>> http://hjemli.net/git/cgit/tree/ui-patch.c
>>
>>
>> In header(), the:
>> 		htmlf("\n--- a/%s\n", path1);
>> 		htmlf("+++ b/%s\n", path2);
>> needs to be conditional on is_null_sha1(sha1)/is_null_sha1(sha2) with
>> the alternative of:
>> 		htmlf("\n--- /%s\n", path1);
>> 		htmlf("+++ /%s\n", path2);
>> which there are a variety of ways to achieve...
>>
>> Michael: Fancy fixing that on the server and sending a patch
>> upstream? :)
>>
>> Cheers,
>>
>> Richard
>>
> I'm happy to. I've fixed the code you've tracked down and recompiled for
> git.yoctoproject.org. You can see the result at
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/patch/?id=ed234aca98d0867c7b32801fc63820b19cf67df9
> but I am still working on fixing the shared UI for this view
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ed234aca98d0867c7b32801fc63820b19cf67df9.
>
>
> Once I have both fixes I'll upgrade http://cgit.openembedded.org/ with
> the new version and submit my patch upstream.
>
I've submitted the patch upstream and installed a fixed copy of cgit on
cgit.openembedded.org. Please let me know if any errors in the
formatting remain.

Michael Halstead
Yocto Project / Sys Admin
Richard Purdie - Nov. 15, 2012, 10:52 a.m.
On Wed, 2012-11-14 at 13:07 -0800, Michael Halstead wrote:
> On 11/14/2012 11:45 AM, Michael Halstead wrote:
> > On 11/14/2012 05:30 AM, Richard Purdie wrote:
> >> On Wed, 2012-11-14 at 13:24 +0000, Richard Purdie wrote:
> >>> On Wed, 2012-11-14 at 13:30 +0100, Martin Jansa wrote:
> >>>> On Tue, Nov 13, 2012 at 01:59:19PM +0000, Richard Purdie wrote:
> >>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>>> ---
> >>>>> diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> >>>>> new file mode 100644
> >>>>> index 0000000..f587c34
> >>>>> --- a/dev/null
> >>>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> >>>>> @@ -0,0 +1,28 @@
> >>>> Are you using some special tool to generate git patches or some weird
> >>>> git version?
> >>> Basically, the data from cgit in the web interface is broken and that is
> >>> causing this.
> >>>
> >>>> Patches from you where you add some file usually does not apply here,
> >>>> It's caused by:
> >>>> --- a/dev/null
> >>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> >>>> which usually looks like
> >>>> --- /dev/null
> >>>> +++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
> >>> Right, there is a bug in cgit. I'm not sure if anyone fancies trying to
> >>> find/fix it?
> >> Actually, its not hard to find:
> >>
> >> http://hjemli.net/git/cgit/tree/ui-patch.c
> >>
> >>
> >> In header(), the:
> >> 		htmlf("\n--- a/%s\n", path1);
> >> 		htmlf("+++ b/%s\n", path2);
> >> needs to be conditional on is_null_sha1(sha1)/is_null_sha1(sha2) with
> >> the alternative of:
> >> 		htmlf("\n--- /%s\n", path1);
> >> 		htmlf("+++ /%s\n", path2);
> >> which there are a variety of ways to achieve...
> >>
> >> Michael: Fancy fixing that on the server and sending a patch
> >> upstream? :)
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> > I'm happy to. I've fixed the code you've tracked down and recompiled for
> > git.yoctoproject.org. You can see the result at
> > https://git.yoctoproject.org/cgit/cgit.cgi/poky/patch/?id=ed234aca98d0867c7b32801fc63820b19cf67df9
> > but I am still working on fixing the shared UI for this view
> > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ed234aca98d0867c7b32801fc63820b19cf67df9.
> >
> >
> > Once I have both fixes I'll upgrade http://cgit.openembedded.org/ with
> > the new version and submit my patch upstream.
> >
> I've submitted the patch upstream and installed a fixed copy of cgit on
> cgit.openembedded.org. Please let me know if any errors in the
> formatting remain.

Thanks for the fast turnaround, its much appreciated! :)

Cheers,

Richard

Patch

diff --git a/meta/recipes-extended/bash/bash-4.2/crossfix.patch b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
new file mode 100644
index 0000000..f587c34
--- a/dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/crossfix.patch
@@ -0,0 +1,28 @@ 
+Adding @CROSS_COMPILE@ to CFLAGS_FOR_BUILD causes errors like:
+
+mkbuiltins.o: In function `open':
+/usr/include/x86_64-linux-gnu/bits/fcntl2.h:54: undefined reference to `xopen'
+mkbuiltins.o: In function `read':
+/usr/include/x86_64-linux-gnu/bits/unistd.h:45: undefined reference to `xread'
+collect2: ld returned 1 exit status
+
+when compiling on a 64 bit x86 build system for a 32 bit x86 target since
+config.h confuses the compiler about settings. By removing the option, config.h 
+isn't used and the compiler stops getting confused.
+
+Upstream-Status: Pending
+RP 2012/11/13
+
+Index: bash-4.2/builtins/Makefile.in
+===================================================================
+--- bash-4.2.orig/builtins/Makefile.in	2010-12-21 13:37:18.000000000 +0000
++++ bash-4.2/builtins/Makefile.in	2012-11-13 11:36:47.761417446 +0000
+@@ -56,7 +56,7 @@
+ 
+ PROFILE_FLAGS = @PROFILE_FLAGS@
+ CFLAGS = @CFLAGS@
+-CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@ @CROSS_COMPILE@
++CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@
+ CPPFLAGS = @CPPFLAGS@
+ CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
+ LOCAL_CFLAGS = @LOCAL_CFLAGS@ ${DEBUG}
diff --git a/meta/recipes-extended/bash/bash_4.2.bb b/meta/recipes-extended/bash/bash_4.2.bb
index 5a0f015..18ddc7e 100644
--- a/meta/recipes-extended/bash/bash_4.2.bb
+++ b/meta/recipes-extended/bash/bash_4.2.bb
@@ -4,7 +4,7 @@  require bash.inc
 LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
-PR = "r5"
+PR = "r6"
 
 SRC_URI = "${GNU_MIRROR}/bash/${BPN}-${PV}.tar.gz;name=tarball \
            ${GNU_MIRROR}/bash/bash-4.2-patches/bash42-001;apply=yes;striplevel=0;name=patch001 \
@@ -18,6 +18,7 @@  SRC_URI = "${GNU_MIRROR}/bash/${BPN}-${PV}.tar.gz;name=tarball \
            ${GNU_MIRROR}/bash/bash-4.2-patches/bash42-009;apply=yes;striplevel=0;name=patch009 \
            ${GNU_MIRROR}/bash/bash-4.2-patches/bash42-010;apply=yes;striplevel=0;name=patch010 \
            file://execute_cmd.patch;striplevel=0 \
+           file://crossfix.patch \
            "
 
 SRC_URI[tarball.md5sum] = "3fb927c7c33022f1c327f14a81c0d4b0"