Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?

From: Gary V. Vaughan <[email-masked]>
Date: Sat, 6 Aug 2011 10:18:52 +0700

Hi Jeff,

On 5 Aug 2011, at 02:37, Jeff Squyres wrote:
> I see lots of references to old versions of Solaris in generated Libtool scripts, but we've recently been told about a problem with the following with Solaris 2.8's sh:
> 
> 	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> % cat ~/trans/basedir.sh
> 
> path="../libtool"
> 
> echo path____ $path
> echo basename ${path##*/}
> echo dirname_ ${path%/*}
> 	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> % /bin/sh ~/trans/basedir.sh
> path____ ../libtool
> /export/home/andreask/trans/basedir.sh: bad substitution
> 	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> The ${foo##*/} pattern is used in the LT 2.4-generated libtool script (e.g., in http://www.open-mpi.org/software/hwloc/v1.2/downloads/hwloc-1.2.tar.bz2).
> 
> Is this a known issue?

The default is to not use these non-portable XSI patterns, and only if a configure time test case
is successful are they spliced into the generated libtool to speed things up.  Perhaps configure
found a better shell and re-executed itself in order for those checks to pass, and then the
generated libtool was passed through the under-powered solaris sh afterwards? 

Here's the snippet from libtool's generated configure script:

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands some XSI constructs" >&5
$as_echo_n "checking whether the shell understands some XSI constructs... " >&6; }
# Try some XSI features
xsi_shell=no
( _lt_dummy="a/b/c"
  test "${_lt_dummy##*/},${_lt_dummy%/*},${_lt_dummy#??}"${_lt_dummy%"$_lt_dummy"}, \
      = c,a/b,b/c, \
    && eval 'test $(( 1 + 1 )) -eq 2 \
    && test "${#_lt_dummy}" -eq 5' ) >/dev/null 2>&1 \
  && xsi_shell=yes
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $xsi_shell" >&5
$as_echo "$xsi_shell" >&6; }

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands \"+=\"" >&5
$as_echo_n "checking whether the shell understands \"+=\"... " >&6; }
lt_shell_append=no
( foo=bar; set foo baz; eval "$1+=\$2" && test "$foo" = barbaz ) \
    >/dev/null 2>&1 \
  && lt_shell_append=yes
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_shell_append" >&5
$as_echo "$lt_shell_append" >&6; }

Which comes from the macro _LT_CHECK_SHELL_FEATURES near the end of `libltdl/m4/libtool.m4'.
In the eventual generated libtool script, all uses of XSI shell features are encapsulated in a hand
full of shell functions marked by the comment "may be replaced by extended shell implementation"
(func_append, func_append_quoted, func_arith, func_len, func_lo2o and func_xform) if the
configure time shell is detected as not supporting XSI features, otherwise those functions are
replace by faster XSI implementations marked by the comment "Extended-shell <func-name> implementation"
by the macro _LT_PROG_FUNCTION_REPLACE.

You might try replacing all of the above with the following to narrow down the problem between XSI
detection issues versus early/incorrect replacement issues:

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands some XSI constructs" >&5
$as_echo_n "checking whether the shell understands some XSI constructs... " >&6; }
# Try some XSI features
xsi_shell=no
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $xsi_shell" >&5
$as_echo "$xsi_shell" >&6; }

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands \"+=\"" >&5
$as_echo_n "checking whether the shell understands \"+=\"... " >&6; }
lt_shell_append=no
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_shell_append" >&5
$as_echo "$lt_shell_append" >&6; }

At configure time you should see 'checking whether the shell understands some XSI constructs...' and
'checking whether the shell understands "+="...' tests, and the generated libtool script should
contain definitions of the shell functions listed above that match the results of those tests.
Similarly, ltmain.sh should always contain the unsubstituted implementations of those functions,
because _LT_PROG_FUNCTION_REPLACE only knows how to splice in the XSI implementations on demand,
and doesn't know how to go back the other way if the configure tests find XSI features don't work.
Can you investigate some more and report your findings back to the list?

HTH,
-- 
Gary V. Vaughan (gary AT gnu DOT org)