RE: config.status (or something) writes out a crippled libtool script

[Peter Ekberg]

Ralf Wildenhues wrote:
> * Peter Ekberg wrote on Wed, Aug 24, 2005 at 07:54:00PM CEST:
> > Ralf Wildenhues wrote:
> > > * Peter Ekberg wrote on Wed, Aug 24, 2005 at 03:40:42PM CEST:
> > > > 3. do a s,/@/,/, on doc/libtool.texi, don't know what's 
> up with my
> > > > makeinfo...
> > > 
> > > Please show exact error output, plus makeinfo version.
> > 
> > WTF, can't reproduce now, it's been like that since forever.
> > Could the resolution be connected to me upgrading automake to cvs
> > from 1.9.5?
> 
> Dunno.  Which texinfo version?

makeinfo (GNU texinfo) 4.8

Copyright (C) 2004 Free Software Foundation, Inc.
There is NO warranty.  You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files named COPYING.

> > > > 10. make
> > > [ triggers ltmain.m4sh -> ltmain.sh recreation ]
> > > > /bin/sh: autom4te: command not found
> > > *snip*
> > > 
> > > Thanks for this report.  Can you try the attached patch?  
> It has the
> > 
> > Seems to work nicely. Thanks!
> 
> Yet it's the wrong fix.  Again.  
> Last time it needed Alexandre to remind us:  No 
> system-specifics may end
> up in ltmain.sh!  Why?  It's used by clients when they libtoolize.
> 
> So, the best would probably be to fill out all the default values from
> $(edit) in Makefile.am and then _not_ touch either of ltmain.{in,m4sh}
> at the end of bootstrap.  And then we don't need to ship ltmain.in
> either.  I think.

This went above my head... :-)

> > > disadvantage that yet another almost-identical copy of 
> ltmain needs to
> > > be shipped in the tarball.  If it works, please also try a 
> > > `make dist',
> > > extract the tarball in a new directory and try configuring 
> > > that on mingw
> > > right away.  Thanks!
> > 
> > I did "./bootstrap; mkdir cygwin; cd cygwin; ../configure"
> > make dist &> make_dist.log
> > 
> > It failed, attaching output...
> 
> You should've attached the output of the ../configure as well (or
> config.log, FWIW).  The question is: did it disable the f77 and the fc
> tests?  If yes, then all is well (maybe not well, but the way 
> things are
> right now): Our test suite does not execute the Fortran tests if no
> compiler installed, but the directories have to be configured in order
> to be packaged.  For packaging the Libtool package itself, that
> currently means you have to have a Fortran compiler.  :-/

f77 and fc are disabled, so I'm not attaching any output...

> Should I look into removing this requirement?
> (AFAIK, you need a C++ compiler as well.)

Not important for me, at least not now. I could just install g77
for cygwin. Should be simple... *time passes* But not enough
g77 can't compile .f90 files. Bummer. Ah well, I guess I will not
be making any releases using cygwin :-)

Cheers,
Peter