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

From: "Gary V. Vaughan" <[email-masked]>
Date: Mon, 24 Oct 2011 13:58:24 +0700

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)