Re: libtool-1.4b bootstrap nit

[Tim Mooney]

In regard to: Re: libtool-1.4b bootstrap nit, Gary V. Vaughan said (at...:

>On Wednesday 11 July 2001  1:17 am, Tim Mooney wrote:
>>
>> If I grab the tarball from alpha.gnu.org and untar it and then
>>
>>      ./bootstrap
>
>No need to bootstrap it yourself unless you fetch from CVS.  The tarballs we
>release are all pre-bootstrapped with a suitable version of autoconf and
>automake.

Understood, but it should work.  The reason I was doing it is that I
eventually plan to apply a couple local patches to libtool, and they will
require that some of the configure machinery be rebuilt.  bootstrap is
the easiest way to do that.  The problem I'm seeing happens even without
any local patches, though.

>>      ./configure
>>      gmake
>
>Don't forget that the make process is recursive, so you also need to `export
>MAKE=gmake' for the submakes to be called correctly.

Thanks for the reminder, but that's not it either.

>> it starts out by doing a recheck:
>>
>>      /bin/ksh ./config.status --recheck
>
>Perhaps there is a broken macro in autoconf or libtool with respect to ksh?

See below.  In fact, I don't even need to rebuild configure to see the
problem -- Just untarring libtool and running configure causes it to happen.
Sorry I didn't notice that before.

>Can you retry with bash as the CONFIG_SHELL and see if that works?

Doesn't make a difference -- though /bin/ksh is still used for the
config.status re-runs.

>> and I eventually see:
>>
>> configure: creating libtool
>> appending configuration tag "CXX" to libtool
>> checking whether the cxx linker (/usr/bin/ld) supports shared libraries...
>> yes ./configure[7903]: syntax error at line 1 : `COPYING' unexpected
>
>Alphabetically, COPYING and Makefile are exactly the second files in their
>respective directories, which makes me think that the quoting in the new tags
>code is not robust to the version of ksh you are running... or possibly the
>version of /bin/sh configure re-execs itself with.  If you can prove this
>somehow, we might be able to beat out a workaround for the next release.

I did some more digging.  The problem is coming from the

        output_verbose_link_cmd

for alpha-dec-osf5.x (the osf4* | osf5* case)

The whole thing is being eval'ed, and apparently the

        *)

for the "catchall" case is therefore being globbed, which results in
a list containing all the files in the current directory.  It doesn't
know how to parse anything beyond the first one, so the shell complains
about it.  If I had to guess, I would bet that any platform where the
same output_verbose_link_cmd is used would cause the same problem.

Looking at some of the other code in libtool.m4, you might be able to
reproduce it on Linux if you use the Compaq cxx compiler, but I don't
even know if that's available for Linux/Intel yet, so you would probably
still need an alpha.  You could probably just test that bit of code
by making it the output_verbose_link_cmd for whatever CXX compiler you are
using, to see if it does the same thing there.  It's not the Right Thing
for other compilers, but it would allow you to test the code itself, to
see if you can reproduce the problem.

>And just to double check (note that the `a' suffix on the version numbers is
>because I have slightly newer than release versions built from CVS -- I hope
>that small difference isn't why you have errors though):

I tried it with autoconf 2.50b, and it also doesn't make any difference.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164