libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool.m4 option to use installed libtool


From: Ralf Wildenhues
Subject: Re: libtool.m4 option to use installed libtool
Date: Fri, 1 Apr 2005 09:15:19 +0200
User-agent: Mutt/1.4.1i

Hi Greg,

* Greg Hudson wrote on Thu, Mar 31, 2005 at 11:56:51PM CEST:
> Periodically, I face situations like this: libtool fails in some
> situation on a new operating system.  The problem is already fixed
> upstream or can be fixed easily, but most of the packages I build are
> packaged with an old version.  Recent examples include the DESTDIR bug
> with relinking in 1.4.x and the Solaris 10 issues with convenience
> libraries and "-z defaultextract".

Yes, acknowledged this happens to people rather often.

> In such situations, I think my current options are to:
> 
>   1. Hack ltmain.sh or aclocal.m4 in all the affected packages.

Let's see.  There are several different ways packages might use libtool.
a) They might rely on an installed libtool script, e.g., /usr/bin/libtool.
b) They might cat libtool.m4 into aclocal.m4 manually, and put ltmain.sh
   into their tree by invoking `libtoolize' with appropriate options.
c) They might cat libtool.m4 into acinclude.m4 manually, rest as in b).
d) They might have a macro directory, say, m4/, where they copy libtool.m4
   and invoke `aclocal -I m4' (plus the libtoolize thing again).  For this,
     ACLOCAL_AMFLAGS = m4
   in $top_srcdir/Makefile.am is good, as then `autoreconf' will invoke
   aclocal correctly by itself

This options has been added to branch-2-0 and newer (plus new Automake):

e) They might put
     AC_CONFIG_MACRO_DIR(m4)
   in configure.ac, then libtoolize will put consistent copies of
   libtool.m4 and ltmain.sh in m4/ resp. the AC_CONFIG_AUX_DIR.
   This ensures you always have both from the same Libtool version.

>   2. Install a fixed libtool and build with "make LIBTOOL=libtool".

Not such a bad idea for a quick workaround.

> Option 2 isn't so bad, but it would be somewhat more convenient for me
> if I could specify the path to libtool in config.site or in the
> configure environment.  I've included a candidate patch.

Hmm.  "Always use our own libtool" sounds a lot like some bug needed
this.  But then again, that line has been in there unchanged for six
years.  I wonder if it will break setups if we change this, it's like
a rope to save us from stupid errors rather than a necessity.

Anybody have good reasons against changing this?

> (Sorry if this comes up a lot.

Not too much, at least lately.

> I couldn't find an easy way to search
> the mail archive, and browsing it is hard since it's full of spam.)

Unfortunate, but this is an issue for the list admins at gnu.org.  AFAIK
quite some spam is filtered, except for the bug-* lists.

Regards,
Ralf

> --- libtool.m4        2005-03-28 04:32:59.000000000 -0500
> +++ libtool.m4.new    2005-03-31 16:03:13.000000000 -0500
> @@ -69,8 +69,9 @@
>  # This can be used to rebuild libtool when needed
>  LIBTOOL_DEPS="$ltmain"
>  
> -# Always use our own libtool.
> -LIBTOOL='$(SHELL) $(top_builddir)/libtool'
> +# Use our own libtool unless the path to one is already specified in
> +# the environment.
> +test -z "$LIBTOOL" && LIBTOOL='$(SHELL) $(top_builddir)/libtool'
>  AC_SUBST(LIBTOOL)dnl
>  
>  # Set options
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]