summaryrefslogtreecommitdiffstats
path: root/meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch
diff options
context:
space:
mode:
Diffstat (limited to 'meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch')
-rw-r--r--meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch26
1 files changed, 26 insertions, 0 deletions
diff --git a/meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch b/meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch
new file mode 100644
index 0000000000..a9391d6cac
--- /dev/null
+++ b/meta/recipes-extended/bash/bash/mkbuiltins_have_stringize.patch
@@ -0,0 +1,26 @@
1On hosts with FORTIFY_SOURCES, stringize support is required, as it's used by
2the macros to wrap functions (e.g. read and open in unistd.h). Those wrappers
3use the STRING() macro from unistd.h. A header in the bash sources overrides
4the unistd.h macro to 'x' when HAVE_STRINGIZE is not defined, causing the
5wrappers to generate calls to 'xread' and 'xopen', which do not exist,
6resulting in a failure to link.
7
8Assume we have stringize support when cross-compiling, which works around the
9issue.
10
11It may be best for upstream to either give up on supporting compilers without
12stringize support, or to not define STRING() at all when FORTIFY_SOURCES is
13defined, letting the unistd.h one be used, instead.
14
15Upstream-Status: Pending
16
17--- bash-4.2.orig/builtins/mkbuiltins.c
18+++ bash-4.2/builtins/mkbuiltins.c
19@@ -28,6 +28,7 @@
20 # define HAVE_STDLIB_H
21
22 # define HAVE_RENAME
23+# define HAVE_STRINGIZE
24 #endif /* CROSS_COMPILING */
25
26 #if defined (HAVE_UNISTD_H)