5174 2013-09-12 13:47:01 +0000 libtool with bashisms enabled in script can be shared through sstate-cache with host where /bin/sh is dash and cause build issues 2013-09-25 09:00:23 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.5.1 x86 Multiple RESOLVED FIXED Medium normal 1.5 M5 1 Martin.Jansa richard.purdie meta.mr.watcher meta.watcher sgw --- --- Don't know oldest_to_newest 36606 0 Martin.Jansa 2013-09-12 13:47:01 +0000 apr-util-native is failing when /bin/sh is dash First reported here: http://lists.openembedded.org/pipermail/openembedded-core/2013-March/076087.html We have some fixes for dash compatibility in libtool since: commit 07ded02ffd37b4fe60a6210dbf56490ea306f0b6 Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Tue Nov 8 21:33:53 2011 +0000 Allow use of dash as /bin/sh but current libtool script is still using var+= in 188 places, e.g. this one breaks apr-util-native build: x86_64-linux-libtool: preserve_args+= --silent: not found surprising that we don't hit one of those more often (maybe they just aren't fatal for build in many cases). And there is few more possible bashisms found by checkbashisms: possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 539 (alias): alias -g '${1+"$@"}'='"$@"' possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 1018 ($RANDOM): my_tmpdir="${my_template}-${RANDOM-0}$$" possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 8251 (shopt): test "$want_nocaseglob" = yes && nocaseglob=`shopt -p nocaseglob` possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 8254 (shopt): shopt -s nocaseglob possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 9525 (trap with signal numbers): trap "$RM $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15 possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 9541 (trap with signal numbers): trap "$RM $func_ltwrapper_scriptname_result; exit $EXIT_FAILURE" 1 2 15 possible bashism in tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool line 9553 (trap with signal numbers): trap "$RM $output; exit $EXIT_FAILURE" 1 2 15 36607 1 Martin.Jansa 2013-09-12 13:53:14 +0000 Ah I see it's probably more complicated than that :). In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518905, I've read: Libtool uses (and exploits features of) the shell it was configured for. The /usr/bin/libtool script has to be used with it. The first line of the script should reflect that, as well as its SHELL= setting. And I see that my libtool script was configured with SHELL=/bin/sh (and /bin/sh -> bash here), but when the same libtool-native is shared with sstate to some other host where /bin/sh -> dash, it will try to use bash features and fail. So the problem is, that sstate signature of libtool doesn't contain system shell (the real shell not just /bin/sh as symlink). 37076 2 richard.purdie 2013-09-23 16:21:20 +0000 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=5eeecef53b430883b89ba1d1020685e2247b3c14 might offer a fix for this. Means patching autoconf unfortunately 37164 3 richard.purdie 2013-09-25 09:00:23 +0000 Fix is in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=49e754aca3a79abfa024472e3528a5dcb7291b41