bug#9249: Does Libtool 2.4 support Solaris 2.8?

[Andreas Kupries]

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
address@hidden
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog