GNU bug report logs -
#9249
Does Libtool 2.4 support Solaris 2.8?
Previous Next
Full log
Message #80 received at submit <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 13 years and 315 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.