[OE-core] [PATCH] bash: Add fix for cross compile issues

[Richard Purdie]

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 at linuxfoundation.org> wrote:
>         Signed-off-by: Richard Purdie
>         <richard.purdie at 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