bug#9848: libtool bootstrap fails with Solaris /bin/sh

[Gary V. Vaughan]

Hi Bob,

On 24 Oct 2011, at 00:00, Bob Friesenhahn wrote:
> On Sun, 23 Oct 2011, Gary V. Vaughan wrote:
>> 
>> On 23 Oct 2011, at 23:19, Bob Friesenhahn wrote:
>>> + func_quote_for_eval + : func_quote_for_eval_result=
>>> + test 0 -gt 0 func_run_hooks_result=
>>> + set dummy + shift func_options_prep_result=
>>> + eval func_parse_options + func_parse_options + : 
>>> func_parse_options_result=
>>> + test 0 -gt 0 + func_quote_for_eval + : func_quote_for_eval_result=
>>> + test 0 -gt 0 func_parse_options_result=
>>> ./bootstrap: bad substitution
>> 
>> Odd.  I took func_quote_for_eval right out of libtool... can you figure out 
>> what particular substitution Solaris /bin/sh chokes on? I guess I broke 
>> something when I unrolled the option parsing loop (again, taken directly 
>> from libtool) to allow plugging additional parse functions in to the 
>> bootstrap execution via bootstrap.conf.
> 
> Libtool does not use /bin/sh on Solaris because it uses the shell selected by 
> autoconf.  This means that libtool's func_quote_for_eval is similarly broken 
> with broken Solaris /bin/sh.

Ugh.

And bootstrap needs to run long before configure is ready, plus I don't want to 
add all the shell re-exec gunk to bootstrap, so the real question is whether we 
want to support solaris /bin/sh.  My inclination is not to worry about it too 
much, since only developers are likely to want to run bootstrap, and if they 
don't have a better shell than /bin/sh on Solaris, then not being able to 
bootstrap libtool is the least of their worries.

On the other hand, if it's an easy fix that doesn't obfuscate or uglify the 
code, then I don't mind tweaking bootstrap to work.  And similarly we should 
probably port any fixes into libtool too for consistency's sake.

WDYT?  Can I talk you into making a patch?

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