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

[Chris Larson]

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.

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.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121113/6b2ec188/attachment-0002.html>