Files
poky/meta/recipes-extended/bash/bash-3.2.57/mkbuiltins_have_stringize.patch
André Draszik 81386beaf0 bash_3.2.x: update recipe version to match what we're shipping
Make sure the recipe version matches what we're
actually shipping, so that tools like cve-check
can do the right thing.

Rather than fetching version 3.2.48 and applying all
patches up to and including version 3.2.57, we just
fetch the latter in the first place.

(From OE-Core rev: 614ac87f2832c5359f371439559be88d6106cd6b)

Signed-off-by: André Draszik <adraszik@tycoint.com>
Acked-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-11-06 23:35:35 +00:00

30 lines
1.0 KiB
Diff

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 <chris_larson@mentor.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
--- 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)