bug#9249: Does Libtool 2.4 support Solaris 2.8?

[Gary V . Vaughan]

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)