Status of libtool 2.2.X?

Braden McDaniel braden at endoframe.com
Fri Oct 17 06:58:38 UTC 2008


On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
> On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten at redhat.com> wrote:
> >
> > My last rebuild showed only ~100 failures, I'm not sure what I've done
> > differently
> > this time. I suspect that the removal of libtool-ltdl and all related
> > packages from
> > my full-install might have caused this and I'm in the process of rebuilding
> > those with libtool-2.
> > I've uploaded the current logs to http://karsten.fedorapeople.org/
> > After a quick glance at them I think that there are quite a few easy fixes,
> > but I still
> > have to find out what causes p.e. the cracklib failure.
> 
> Looking at the first few:
> 
> afflib: needs AC_PROG_CXX

Or better, just call autoconf instead of autoreconf.  (Or do it right
and patch configure.)

> amanda: aclocal not told where macros are, end up using old libtool m4 macros

The problem is that libtoolize is getting run at all.

> aplus-fsf: needs AC_PROG_CXX

Wow... This one's a mess.  I don't think that's the problem.  In fact,
I'm not convinced the problem with this package has anything to do with
libtool2.  It's hard to see what's going on amid all the warnings about
this code that the compiler is spewing; but if you scroll down to the
bottom you'll see it's just missing something that goes after a -L flag;
presumably some variable isn't getting set for some reason.

> apr: script manually copying libtool files and getting it wrong (just
> use autoreconf!)

Or don't.  I don't see any reason to regenerate configure in this
package.  Only Makefile.in is getting patched.

> avahi: needs AC_PROG_CXX

Again, this looks like a case where autoreconf doesn't need to be run at
all.

> ax25-apps: looks like aclocal was run, but libtoolize wasn't, causing
> mismatch between macros and ltmain.sh

I see this patching a couple of Makefile.am's; running automake should
be sufficient.  Eliding the calls to aclocal and autoconf should avoid
the problem.

> bind: aclocal not told where macros are, end up using old libtool m4 macros

It's not clear to me why this spec file is running libtoolize and
aclocal at all.

> blackbox: needs AC_PROG_CXX

I see no reason at all for this to be running autoreconf. (A comment
claims it gets rid of an rpath; I'd be a little surprised if this were
still true.)

> bmpx: needs AC_PROG_CXX

Actually, the problem is that it patches both configure.ac and
configure.  Presumably the timestamps don't line up right as a result
and "make" triggers regenerating stuff.  Either the patch to
configure.ac should be culled or the timestamps need massaging.
(There's also a patch to soup.m4 that just looks goofy.)

> bzflag: needs AC_PROG_CXX

I see no reason to call autoreconf here.

> cairo-dock: needs AC_PROG_CXX

Yikes. There's a bunch of magic happening here (of dubious value IMO;
but clearly the maintainer doesn't share that view).  I'm really not
sure what to say here.

> compat-db: libtool macros copied manually and getting it wrong

Yeah, more unusual stuff that's just very breakage-prone.  Hard to say
if there's a better way without some deep knowledge of this package.

> cracklib: yeah, failing on --tag=CC is very weird, especially when
> configure.in seems completely reasonable

Pulling in new libtool here is really unnecessary.  The package could
simply run autoconf instead of autoreconf.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>





More information about the fedora-devel-list mailing list