summaryrefslogtreecommitdiff
path: root/meta/site/mips64-linux-uclibc
diff options
context:
space:
mode:
authorChristopher Larson <chris_larson@mentor.com>2012-11-14 07:55:09 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2012-11-14 15:57:13 +0000
commitf7a25dd72d1d463eb72d48c6f9dd968d376496c0 (patch)
tree08c8077da5aba3ace4ab06ef4ad5a73463227d20 /meta/site/mips64-linux-uclibc
parent172a74c540378149eec493c37c030e9f42f9603d (diff)
downloadopenembedded-core-f7a25dd72d1d463eb72d48c6f9dd968d376496c0.tar.gz
openembedded-core-f7a25dd72d1d463eb72d48c6f9dd968d376496c0.tar.bz2
openembedded-core-f7a25dd72d1d463eb72d48c6f9dd968d376496c0.zip
bash: fix mkbuiltins build failure
On hosts with FORTIFY_SOURCES, stringize support is required, as it's used by the macros to wrap functions (e.g. read and open in unistd.h). Those wrappers use the STRING() macro from unistd.h. A header in the bash sources overrides the unistd.h macro to 'x' when HAVE_STRINGIZE is not defined, causing the wrappers to generate calls to 'xread' and 'xopen', which do not exist, resulting in a failure to link. Assume we have stringize support when cross-compiling, which works around the issue. It may be best for upstream to either give up on supporting compilers without stringize support, or to not define STRING() at all when FORTIFY_SOURCES is defined, letting the unistd.h one be used, instead. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/site/mips64-linux-uclibc')
0 files changed, 0 insertions, 0 deletions