From 972dcfcdbfe75dcfeb777150c136576cf1a71e99 Mon Sep 17 00:00:00 2001 From: Tudor Florea Date: Fri, 9 Oct 2015 22:59:03 +0200 Subject: initial commit for Enea Linux 5.0 arm Signed-off-by: Tudor Florea --- .../bash-3.2.48/mkbuiltins_have_stringize.patch | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 meta/recipes-extended/bash/bash-3.2.48/mkbuiltins_have_stringize.patch (limited to 'meta/recipes-extended/bash/bash-3.2.48/mkbuiltins_have_stringize.patch') diff --git a/meta/recipes-extended/bash/bash-3.2.48/mkbuiltins_have_stringize.patch b/meta/recipes-extended/bash/bash-3.2.48/mkbuiltins_have_stringize.patch new file mode 100644 index 0000000000..c4229a7ed9 --- /dev/null +++ b/meta/recipes-extended/bash/bash-3.2.48/mkbuiltins_have_stringize.patch @@ -0,0 +1,29 @@ +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. + +Upstream-Status: Pending + +Signed-off-by: Christopher Larson +Signed-off-by: Saul Wold + +--- bash-4.2.orig/builtins/mkbuiltins.c ++++ bash-4.2/builtins/mkbuiltins.c +@@ -28,6 +28,7 @@ + # define HAVE_STDLIB_H + + # define HAVE_RENAME ++# define HAVE_STRINGIZE + #endif /* CROSS_COMPILING */ + + #if defined (HAVE_UNISTD_H) -- cgit v1.2.3-54-g00ecf