Bug 5174 - libtool with bashisms enabled in script can be shared through sstate-cache with host where /bin/sh is dash and cause build issues
Summary: libtool with bashisms enabled in script can be shared through sstate-cache wi...
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: devtools / tool chain (show other bugs)
Version: 1.5.1
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.5 M5
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-09-12 13:47 UTC by Martin Jansa
Modified: 2013-09-25 09:00 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Jansa 2013-09-12 13:47:01 UTC 
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
Comment 1 Martin Jansa 2013-09-12 13:53:14 UTC 
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).
Comment 2 Richard Purdie 2013-09-23 16:21:20 UTC 
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=5eeecef53b430883b89ba1d1020685e2247b3c14 might offer a fix for this. Means patching autoconf unfortunately