From b00be59bbc49535097c450b6b8c5fc10c1efd6dd Mon Sep 17 00:00:00 2001 From: John Klug Date: Wed, 11 Nov 2020 18:48:27 -0600 Subject: Merge multiarch project to: added missing index file 2020 June 11 --- .../bash/bash-4.2/mkbuiltins_have_stringize.patch | 26 ---------------------- 1 file changed, 26 deletions(-) delete mode 100644 recipes-extended/bash/bash-4.2/mkbuiltins_have_stringize.patch (limited to 'recipes-extended/bash/bash-4.2/mkbuiltins_have_stringize.patch') diff --git a/recipes-extended/bash/bash-4.2/mkbuiltins_have_stringize.patch b/recipes-extended/bash/bash-4.2/mkbuiltins_have_stringize.patch deleted file mode 100644 index a9391d6..0000000 --- a/recipes-extended/bash/bash-4.2/mkbuiltins_have_stringize.patch +++ /dev/null @@ -1,26 +0,0 @@ -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 - ---- 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