Beating libtool into submission [UK Linux]

Prev: thunderbird has lost some articles how to re-get/restore them
Next: Earn Online, Want to know how?

From: Simon J. Rowe on 3 Oct 2009 13:00

I'm trying to rebuild the newest version of sane-backends and have run up
against an error from libtool

+ make
cd . && /bin/sh /home/srowe/rpmbuild/BUILD/sane-
backends-1.0.20/iscan-2.10.0/missing --run aclocal-1.9 -I m4
configure.ac:200: error: unknown libltdl build type: _LTDL_TYPE
/usr/share/aclocal/ltdl.m4:220: LTDL_INIT is expanded from...
/usr/share/aclocal/ltdl.m4:346: AC_LIB_LTDL is expanded from...
configure.ac:200: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal-1.9: autom4te failed with exit status: 1
make: *** [aclocal.m4] Error 1

I have had a hate/hate relationship with libtool, auto* etc for many years.
They are mind-bogglingly over-engineered and fragile. I don't know why
anyone in their right mind would ever consider using them.

Any ideas what's required to conquer libtool here?

Simon

From: Nix on 5 Oct 2009 16:44

On 3 Oct 2009, Simon J. Rowe said:

> I'm trying to rebuild the newest version of sane-backends and have run up
> against an error from libtool
>
> + make
> cd . && /bin/sh /home/srowe/rpmbuild/BUILD/sane-
> backends-1.0.20/iscan-2.10.0/missing --run aclocal-1.9 -I m4
> configure.ac:200: error: unknown libltdl build type: _LTDL_TYPE
> /usr/share/aclocal/ltdl.m4:220: LTDL_INIT is expanded from...
> /usr/share/aclocal/ltdl.m4:346: AC_LIB_LTDL is expanded from...
> configure.ac:200: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal-1.9: autom4te failed with exit status: 1
> make: *** [aclocal.m4] Error 1

The problem here is that something, probably a skewed datestamp (from a
version control system that doesn't store them?) has concluded that
aclocal.m4 is older than acinclude.m4, and has rebuilt it. You've ended
up pulling in a libtool.m4 from a different version of libtool than that
used to build configure.ac in the first place, and *whoom* instant
problems.

Solution simple:

autoreconf -fiv

.... and you should be happy.

> I have had a hate/hate relationship with libtool, auto* etc for many years.
> They are mind-bogglingly over-engineered and fragile. I don't know why
> anyone in their right mind would ever consider using them.

Because for sheer portability nothing else comes close. Look at gnulib one of
these days and try to figure out how the hell else to do some of the amazing
things it does in there.

Well, that's Autoconf. Automake is rather nastier. Libtool is much
worse, but Libtool 2.2 isn't actually repulsively slow or actively
developer-hostile anymore, so I can tolerate it.

From: Simon J. Rowe on 6 Oct 2009 15:33

Nix wrote:

> The problem here is that something, probably a skewed datestamp (from a
> version control system that doesn't store them?) has concluded that
> aclocal.m4 is older than acinclude.m4, and has rebuilt it. You've ended
> up pulling in a libtool.m4 from a different version of libtool than that
> used to build configure.ac in the first place, and *whoom* instant
> problems.
>
> Solution simple:
>
> autoreconf -fiv
>
> ... and you should be happy.

Thanks for the hint. I placed that line before the autoconf and the result
was:

+ cd iscan-2.10.0
+ autoreconf -fiv
autoreconf: Entering directory `.'
autoreconf: running: autopoint --force
Copying file mkinstalldirs
Copying file po/Makevars.template
autoreconf: running: aclocal --force -I m4
configure.ac:200: error: unknown libltdl build type: _LTDL_TYPE
/usr/share/aclocal/ltdl.m4:220: LTDL_INIT is expanded from...
/usr/share/aclocal/ltdl.m4:346: AC_LIB_LTDL is expanded from...
configure.ac:200: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

> Because for sheer portability nothing else comes close. Look at gnulib one
> of these days and try to figure out how the hell else to do some of the
> amazing things it does in there.

My view is there has to be a limit to the amount of pain and inconvenience
you give developers in the name of portability. I could care less if there
was a bug in a 15 year old version of the C compiler on HPUX, especially if
it means my build process goes through multiple layers of indirection to
work around it.

> Well, that's Autoconf. Automake is rather nastier. Libtool is much
> worse, but Libtool 2.2 isn't actually repulsively slow or actively
> developer-hostile anymore, so I can tolerate it.

I've never used them as a direct developer, I have wasted days trying to
diagnose bugs arising from these tools when using third-party code.

Simon

From: Simon J. Rowe on 6 Oct 2009 16:07

From: Tony Houghton on 6 Oct 2009 16:12

On Tue, 06 Oct 2009 20:33:14 +0100
"Simon J. Rowe" <srowe(a)mose.org.uk> wrote:

> Nix wrote:

[Why do people use autoconf etc?]

> > Because for sheer portability nothing else comes close. Look at gnulib one
> > of these days and try to figure out how the hell else to do some of the
> > amazing things it does in there.
>
> My view is there has to be a limit to the amount of pain and inconvenience
> you give developers in the name of portability. I could care less if there
> was a bug in a 15 year old version of the C compiler on HPUX, especially if
> it means my build process goes through multiple layers of indirection to
> work around it.

I agree. Since I added gettext support to roxterm my autotools bootstrap
script throws up loads of warnings that you're supposed to be able to
get rid of by reordering macros, but I can't. And its dependency
tracking is unreliable IME. I've just started using scons, and even if I
didn't know python already I reckon it would still be easier to use that
for the first time than use autotools again :-). Most of my code
involves glib these days anyway and that takes care of compatibility for
you.

--
TH * http://www.realh.co.uk

|
Pages: 1
Prev: thunderbird has lost some articles how to re-get/restore them
Next: Earn Online, Want to know how?