GNU bug report logs - #9249
Does Libtool 2.4 support Solaris 2.8?

Previous Next

To reply to this bug, email your comments to 9249 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Squyres <jsquyres <at> cisco.com>
To: bug-libtool <at> gnu.org
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>,
	Andreas Kupries <andreask <at> ActiveState.com>,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Does Libtool 2.4 support Solaris 2.8?
Date: Thu, 4 Aug 2011 15:37:12 -0400

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?

-- 
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gary V. Vaughan <gary <at> vaughan.pe>
To: Jeff Squyres <jsquyres <at> cisco.com>,
 bug-libtool <at> gnu.org
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Andreas Kupries <andreask <at> ActiveState.com>,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
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)

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: "Gary V. Vaughan" <gary <at> vaughan.pe>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Fri, 05 Aug 2011 20:54:41 -0700

On 05/08/11 08:18 PM, Gary V. Vaughan wrote:
> 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:
>> 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

I can attest that the generated libtool does contain these patterns.

> 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?

Interesting.

[elided libtool.m4 stuff]

> 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?

I will investigate Monday, when I am back in the office, with access to 
the box in question.

---
Andreas

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: "Gary V. Vaughan" <gary <at> vaughan.pe>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 08 Aug 2011 12:50:32 -0700

On 8/5/2011 8:18 PM, Gary V. Vaughan wrote:
> Here's the snippet from libtool's generated configure script:

Found it ...

> Can you investigate some more and report your findings back to the list?

Sure.

First, from a plain run, no modifications ... My log file shows

	CONF checking whether the shell understands some XSI constructs... yes
	CONF checking whether the shell understands "+="... yes

Given that the code snippet seems to check the shell executing the configure 
script this is to be expected, as I am explicitly using bash to run all my 
configure scripts.

/Configure Run
[/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/build]: executing 
bash ../../src/configure 
--prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install 
--exec-prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install 
--with-tcl=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --with-tk=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib 
--enable-shared --enable-threads
	bash = /usr/local/bin/bash
CONF
[... remainder of the log]

The generated Makefile and libtool however have SHELL=/bin/sh
assignments in them, and without me forcing them to use bash they fiail.


Next up, your proposed modification to force them into the belief of not having 
a XSI shell available.

Now the log contains

	CONF checking whether the shell understands some XSI constructs... no
	CONF checking whether the shell understands "+="... no

The generated Makefile and libtool script also contain SHELL=/bin/sh, and
the build works.


So, what seems to happen is that during the generation of Makefile and libtool 
the shell is always set as "/bin/sh", regardless of which shell was used to run 
the configure (bash in my case), and this can then lead to a mismatch between 
what configure thinks it has available as features (XSI  yes), versus the 
features of the actual shell used during the build (XSI no).


> 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.
>


-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andreask <at> activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Squyres <jsquyres <at> cisco.com>
To: Andreas Kupries <andreask <at> activestate.com>
Cc: "Gary V. Vaughan" <gary <at> vaughan.pe>, 9249 <at> debbugs.gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>, bug-libtool <at> gnu.org,
	Samuel Thibault <samuel.thibault <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 8 Aug 2011 16:08:12 -0400

On Aug 8, 2011, at 3:50 PM, Andreas Kupries wrote:

> First, from a plain run, no modifications ... My log file shows
> 
> 	CONF checking whether the shell understands some XSI constructs... yes
> 	CONF checking whether the shell understands "+="... yes
> 
> Given that the code snippet seems to check the shell executing the configure script this is to be expected, as I am explicitly using bash to run all my configure scripts.

What happens if you run configure in sh (not bash)?

-- 
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Andreas Kupries <andreask <at> activestate.com>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Tue, 9 Aug 2011 03:09:31 +0700

Hi Andreas,

On 9 Aug 2011, at 02:50, Andreas Kupries wrote:
> On 8/5/2011 8:18 PM, Gary V. Vaughan wrote:
>> Here's the snippet from libtool's generated configure script:
> 
> Found it ...
> 
> > Can you investigate some more and report your findings back to the list?
> 
> Sure.

Thanks for following up.

> bash ../../src/configure --prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --exec-prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --with-tcl=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --with-tk=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --enable-shared --enable-threads
> [[...]]
> The generated Makefile and libtool however have SHELL=/bin/sh
> assignments in them, and without me forcing them to use bash they [[fail]].

Ah, I see the problem.

You needn't tell Autotools that you have a preferred shell to the one it looks for by itself (and actually, if you just let configure run with whatever shell it can get, it might even find and choose /usr/local/bin/bash provided that you have /usr/local/bin in your command search PATH, and provided that there is not a shell called 'sh' also somewhere in PATH that provides all the features Autotools is looking for.

    as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
    for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
    do
      IFS=$as_save_IFS
      test -z "$as_dir" && as_dir=.
      case $as_dir in
         /*)
           for as_base in sh bash ksh sh5; do
             as_candidate_shells="$as_candidate_shells $as_dir/$as_base"
           done;;
      esac
    done
    IFS=$as_save_IFS

Generally, bash is an excellent shell to use interactively, but it is a little buggy and considerably slower than some of the cut down shells  such as Debian's /bin/sh which is a link to the lightning fast Almqvist shell. Unless you are experiencing real problems with the shell that configure selects for you, then you probably shouldn't need to force another shell.

However, you can safely force an alternative shell to execute the various Autotools scripts by setting both SHELL and CONFIG_SHELL, like so:

   ./configure SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash <other arguments as usual>

That should ensure that SHELL is then set correctly in libtool and Makefile to match the tests that configure ran earlier.

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

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: Jeff Squyres <jsquyres <at> cisco.com>
Cc: "Gary V. Vaughan" <gary <at> vaughan.pe>, 9249 <at> debbugs.gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>, bug-libtool <at> gnu.org,
	Samuel Thibault <samuel.thibault <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 08 Aug 2011 13:24:17 -0700

On 8/8/2011 1:08 PM, Jeff Squyres wrote:
> On Aug 8, 2011, at 3:50 PM, Andreas Kupries wrote:
>
>> First, from a plain run, no modifications ... My log file shows
>>
>> 	CONF checking whether the shell understands some XSI constructs... yes
>> 	CONF checking whether the shell understands "+="... yes
>>
>> Given that the code snippet seems to check the shell executing the configure script this is to be expected, as I am explicitly using bash to run all my configure scripts.
>
> What happens if you run configure in sh (not bash)?

executing sh ../../src/configure ...
	sh = /usr/bin/sh
CONF
[...]
CONF checking whether the shell understands some XSI constructs... yes
CONF checking whether the shell understands "+="... no

And the build works.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andreask <at> activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 08 Aug 2011 13:31:21 -0700

On 8/8/2011 1:09 PM, Gary V. Vaughan wrote:
> Hi Andreas,
>
> On 9 Aug 2011, at 02:50, Andreas Kupries wrote:
>> On 8/5/2011 8:18 PM, Gary V. Vaughan wrote:
>>> Here's the snippet from libtool's generated configure script:
>>
>> Found it ...
>>
>>> Can you investigate some more and report your findings back to the list?
>>
>> Sure.
>
> Thanks for following up.
>
>> bash ../../src/configure --prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --exec-prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --with-tcl=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --with-tk=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --enable-shared --enable-threads
>> [[...]]
>> The generated Makefile and libtool however have SHELL=/bin/sh
>> assignments in them, and without me forcing them to use bash they [[fail]].
>
> Ah, I see the problem.
>
> You needn't tell Autotools that you have a preferred shell

Wel, I was not reall aware of telling it about a prefered shell, just executing 
configure via bash.

Actually, I am kind of surpised that it is apparently possible to run configure 
with a shell A, under which tests are run, and then having it generate files 
for a shell B it considers preferable, but was not tested against.

> to the one it looks for by itself (and actually, if you just let configure 
run with whatever shell it can get,
> it might even find and choose /usr/local/bin/bash provided that you have 
/usr/local/bin in your command search
> PATH, and provided that there is not a shell called 'sh' also somewhere in 
PATH that provides all the features
> Autotools is looking for.

So, is 'configure' re-exec'uting itself with a different shell, if it finds 
whatever it prefers ?

>
>      [snippet elided]
>
> Generally, bash is an excellent shell to use interactively, but it is a little buggy and considerably slower
> than some of the cut down shells  such as Debian's /bin/sh which is a link 
to the lightning fast Almqvist shell.
> Unless you are experiencing real problems with the shell that configure 
selects for you, then you probably shouldn't need to force another shell.

bash is simply the shell of choice here for both interactive and scripting use. 
Which we know to have everywhere, with a consistent set of features.

> However, you can safely force an alternative shell to execute the various Autotools scripts by setting both SHELL and CONFIG_SHELL, like so:
>
>     ./configure SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash<other arguments as usual>

Is it possible to set this through the environment as well ? (It might be 
easier for the build setup here to put this into the environment of ./configure 
when it is run. Have to re-check).

I should note that SHELL is set in the global environment too, to 'path/to/bash'.
Its apparently only CONFIG_SHELL I might have to set.

> That should ensure that SHELL is then set correctly in libtool and Makefile to match the tests that configure ran earlier.

Thanks for all the help.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andreask <at> activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Squyres <jsquyres <at> cisco.com>
To: Andreas Kupries <andreask <at> activestate.com>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>, bug-libtool <at> gnu.org,
	"Gary V. Vaughan" <gary <at> gnu.org>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 8 Aug 2011 16:38:45 -0400

On Aug 8, 2011, at 4:31 PM, Andreas Kupries wrote:

>> However, you can safely force an alternative shell to execute the various Autotools scripts by setting both SHELL and CONFIG_SHELL, like so:
>> 
>>    ./configure SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash<other arguments as usual>
> 
> Is it possible to set this through the environment as well ? (It might be easier for the build setup here to put this into the environment of ./configure when it is run. Have to re-check).

Yes.  You can export SHELL and CONFIG_SHELL before invoking configure to the same effect.

I tend to prefer putting them on the configure command line, though, because then they show up in config.log (i.e., the log of everything that configure did).  If you put them in the environment (vs. the command line), the config.log is potentially missing some important information about the configuration.

But it's just a personal preferance.

-- 
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Squyres <jsquyres <at> cisco.com>
To: Andreas Kupries <andreask <at> activestate.com>
Cc: "Gary V. Vaughan" <gary <at> vaughan.pe>, 9249 <at> debbugs.gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>, bug-libtool <at> gnu.org,
	Samuel Thibault <samuel.thibault <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 8 Aug 2011 16:40:05 -0400

On Aug 8, 2011, at 4:24 PM, Andreas Kupries wrote:

>> What happens if you run configure in sh (not bash)?
> 
> executing sh ../../src/configure ...
> 	sh = /usr/bin/sh
> CONF
> [...]
> CONF checking whether the shell understands some XSI constructs... yes
> CONF checking whether the shell understands "+="... no
> 
> And the build works.

Ok, good.

It wasn't clear to me that you were explicitly running configure in bash before, and then the makefiles were defaulting to sh.

All is now explained.

Thanks, libtool people!

-- 
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Message #62 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: Jeff Squyres <jsquyres <at> cisco.com>
Cc: "Gary V. Vaughan" <gary <at> vaughan.pe>, 9249 <at> debbugs.gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>, bug-libtool <at> gnu.org,
	Samuel Thibault <samuel.thibault <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 08 Aug 2011 13:39:45 -0700

On 8/8/2011 1:40 PM, Jeff Squyres wrote:
> On Aug 8, 2011, at 4:24 PM, Andreas Kupries wrote:
>
>>> What happens if you run configure in sh (not bash)?
>>
>> executing sh ../../src/configure ...
>> 	sh = /usr/bin/sh
>> CONF
>> [...]
>> CONF checking whether the shell understands some XSI constructs... yes
>> CONF checking whether the shell understands "+="... no
>>
>> And the build works.
>
> Ok, good.
>
> It wasn't clear to me that you were explicitly running configure in bash before, and then the makefiles were defaulting to sh.

I see. Yeah, that is what I'm doing.
I will find a way from here now.

> All is now explained.
> Thanks, libtool people!

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andreask <at> activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Andreas Kupries <andreask <at> activestate.com>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Tue, 9 Aug 2011 03:54:49 +0700

Hi Andreas,

On 9 Aug 2011, at 03:31, Andreas Kupries wrote:
> On 8/8/2011 1:09 PM, Gary V. Vaughan wrote:
>> On 9 Aug 2011, at 02:50, Andreas Kupries wrote:
>>> On 8/5/2011 8:18 PM, Gary V. Vaughan wrote:
>>> bash ../../src/configure --prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --exec-prefix=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install --with-tcl=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --with-tk=/export/home/andreask/dbn/BuildTmp/Hwloc/solaris2.8-sparc/install/lib --enable-shared --enable-threads
>>> [[...]]
>>> The generated Makefile and libtool however have SHELL=/bin/sh
>>> assignments in them, and without me forcing them to use bash they [[fail]].
>> 
>> Ah, I see the problem.
>> 
>> You needn't tell Autotools that you have a preferred shell
> 
> Wel, I was not reall aware of telling it about a prefered shell, just executing configure via bash.
> 
> Actually, I am kind of surpised that it is apparently possible to run configure with a shell A, under which tests are run, and then having it generate files for a shell B it considers preferable, but was not tested against.

What happens here is that you're effectively going behind configure's back when you use '/path/to/some/shell ./configure...', because there is no way for it know that it isn't simple running inside the default shell.

> > to the one it looks for by itself (and actually, if you just let configure run with whatever shell it can get,
> > it might even find and choose /usr/local/bin/bash provided that you have /usr/local/bin in your command search
> > PATH, and provided that there is not a shell called 'sh' also somewhere in PATH that provides all the features
> > Autotools is looking for.
> 
> So, is 'configure' re-exec'uting itself with a different shell, if it finds whatever it prefers ?

Yes, exactly that, unless the shell it happens to be inside already works satisfactorily.

>> However, you can safely force an alternative shell to execute the various Autotools scripts by setting both SHELL and CONFIG_SHELL, like so:
>> 
>>    ./configure SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash<other arguments as usual>
> 
> Is it possible to set this through the environment as well ? (It might be easier for the build setup here to put this into the environment of ./configure when it is run. Have to re-check).

No, because ./configure needs to know that you want to generate a Makefile that executes libtool with a particular non-discovered shell.  Much the same as you need to override internal Makefile variables explicitly with 'make SED=gsed', you also need to inform configure that you want to override its shell search and re-exec with 'configure SHELL=/path/to/bash CONFIG_SHELL=/path/to/bash', so that it can pass that knowledge through to the rest of the build.

Actually, configure and libtool are both written extremely carefully to work well with a very basic shell, so you're not buying yourself anything but a longer wait by forcing the use of bash.  It's all well and good that you want to write and execute your own scripts in Bash, but I don't see the advantage in forcing Autotools to use the much slower bash when the developers of Autotools have gone to great lengths to dynamically select the best available shell to execute themselves quickly and correctly.

> I should note that SHELL is set in the global environment too, to 'path/to/bash'.
> Its apparently only CONFIG_SHELL I might have to set.

Yes, that's right.

>> That should ensure that SHELL is then set correctly in libtool and Makefile to match the tests that configure ran earlier.
> 
> Thanks for all the help.

You're welcome.

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

Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Squyres <jsquyres <at> cisco.com>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Andreas Kupries <andreask <at> activestate.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 8 Aug 2011 17:02:24 -0400

On Aug 8, 2011, at 4:54 PM, Gary V. Vaughan wrote:

>> Is it possible to set this through the environment as well ? (It might be easier for the build setup here to put this into the environment of ./configure when it is run. Have to re-check).
> 
> No, because ./configure needs to know that you want to generate a Makefile
> [snip] 

Oops.  I stand corrected.

FWIW, it *is* possible to do this with other variables, like CC, CFLAGS, and friends.  But that's kinda beside the point here.  :-)

-- 
Jeff Squyres
jsquyres <at> cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Message #80 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Kupries <andreask <at> activestate.com>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: Samuel Thibault <samuel.thibault <at> inria.fr>, 9249 <at> debbugs.gnu.org,
	Jeff Squyres <jsquyres <at> cisco.com>, bug-libtool <at> gnu.org,
	Brice Goglin <Brice.Goglin <at> inria.fr>
Subject: Re: bug#9249: Does Libtool 2.4 support Solaris 2.8?
Date: Mon, 08 Aug 2011 14:03:58 -0700

On 8/8/2011 1:54 PM, Gary V. Vaughan wrote:
> Hi Andreas,
>
>> Wel, I was not reall aware of telling it about a prefered shell, just executing configure via bash.
>>
>> Actually, I am kind of surpised that it is apparently possible to run configure with a shell A, under which tests are run, and then having it generate files for a shell B it considers preferable, but was not tested against.
>
> What happens here is that you're effectively going behind configure's back when you use '/path/to/some/shell ./configure...', because there is no way for it know that it isn't simple running inside the default shell.

Hm. Ok.

>>> to the one it looks for by itself (and actually, if you just let configure run with whatever shell it can get,
>>> it might even find and choose /usr/local/bin/bash provided that you have /usr/local/bin in your command search
>>> PATH, and provided that there is not a shell called 'sh' also somewhere in PATH that provides all the features
>>> Autotools is looking for.
>>
>> So, is 'configure' re-exec'uting itself with a different shell, if it finds whatever it prefers ?
>
> Yes, exactly that, unless the shell it happens to be inside already works satisfactorily.

Ok.

>>> However, you can safely force an alternative shell to execute the various Autotools scripts by setting both SHELL and CONFIG_SHELL, like so:
>>>
>>>     ./configure SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash<other arguments as usual>
>>
>> Is it possible to set this through the environment as well ? (It might be easier for the build setup here to put this into the environment of ./configure when it is run. Have to re-check).
>
> No, because ./configure needs to know that you want to generate a Makefile that executes libtool with a particular non-discovered shell.  Much the same as you need to override internal Makefile variables explicitly with 'make SED=gsed', you also need to inform configure that you want to override its shell search and re-exec with 'configure SHELL=/path/to/bash CONFIG_SHELL=/path/to/bash', so that it can pass that knowledge through to the rest of the build.

Ok. I checked, I have methods in my build code to put this stuff on the 
configure cmdline (not env). Actually tried it already, and it is working.

> Actually, configure and libtool are both written extremely carefully to work well with a very basic shell, so you're not buying yourself anything but a longer wait by forcing the use of bash.  It's all well and good that you want to write and execute your own scripts in Bash, but I don't see the advantage in forcing Autotools to use the much slower bash when the developers of Autotools have gone to great lengths to dynamically select the best available shell to execute themselves quickly and correctly.

Heh.

Well, given that I am in the middle of doing builds/distributions going to 
customers I will not play with the overall build system right now, I won't even 
commit the SHELL/CONFIG_SHELL change, given that this would be in a central 
shared file, i.e. have a global effect. All these test builds for hwloc were 
luckily semi-local and produce something which is not going into these 
distributions, so I was able to run them alongside my release builds without 
breaking or influencing them.

However, when I am done with these builds I believe will play around a bit 
again, i.e. try out using 'sh', vs. 'bash', vs. not setting an explicit shell 
to run configure, etc., and see if something else breaks, speed differences etc.

For now I am comfortable that I understand the issue at hand and have various 
solutions and workarounds available to me.

>> I should note that SHELL is set in the global environment too, to 'path/to/bash'.
>> Its apparently only CONFIG_SHELL I might have to set.
>
> Yes, that's right.
>
>>> That should ensure that SHELL is then set correctly in libtool and Makefile to match the tests that configure ran earlier.
>>
>> Thanks for all the help.
>
> You're welcome.
>
> Cheers,


-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andreask <at> activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.