[Top][All Lists]

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

Re: conditionally using libtool

From: Bob Rossi
Subject: Re: conditionally using libtool
Date: Sat, 29 Apr 2006 12:18:54 -0400
User-agent: Mutt/1.5.9i

On Sat, Apr 29, 2006 at 05:50:41PM +0200, Ralf Wildenhues wrote:
> * Bob Rossi wrote on Sat, Apr 29, 2006 at 12:15:49PM CEST:
> > On Sat, Apr 29, 2006 at 09:09:19AM +0200, Ralf Wildenhues wrote:
> > > * Bob Rossi wrote on Sat, Apr 29, 2006 at 04:00:03AM CEST:
> > > > 
> > > > Can I do something in that says 
> > > >   if .. 
> > > >     AM_LIBTOOL
> > > >   fi;
> > > > 
> > > > or is this invalid?
> > > 
> > > This is invalid and will break at unfortunate places.
> > Thanks for the advice. This was definatly a typo on my part. I'm using
> > However, I was burned before by putting a macro in an 'if' statement.
> Right.
> > I was wondering if it was OK to use AC_PROG_LIBTOOL in an if
> > statement.
> No.  To put it very explicitly: the code Russ posted may cause seemingly
> unrelated breakage.  You get to keep the pieces.  And yes, it also may
> "just happen to work".
> One example for why it may break in really weird ways: say, you use two
> macros which both AC_REQUIRE([AC_PROG_SED]) (which is a realistic
> situation when Autoconf-2.60 and Libtool-2.0 are out).  Say
> AC_PROG_LIBTOOL happens to be used earlier in, like this:
>   if $whatever; then
>   fi
> then the expansion of AC_PROG_SED will happen right after the if
> condition.  The other macro that needs it, which, say, is called
> unconditionally, will assume AC_PROG_SED has already been expanded.
> But if $whatever turns out to be false, the corresponding code will
> not be run.
> The AS_IF of Autoconf-2.60 will mediate this somewhat.  But until
> then I can only warn of such usage.

OK, so is the only safe way to do this to have 2 scripts?
One that uses AC_PROG_LIBTOOL and one that doesn't?

Or could I use m4 to bring in the macro definition or not, instead of
relying on the sh code?

Finally, I have a related question. I have a package that has a
--enable-tcl-extension feature. By default the package makes a static
library using AC_PROG_RANLIB. However, with --enable-tcl-extension, I 
need to make a .so, so that tcl can load it. I'm obviously thinking
about using AC_PROG_LIBTOOL to do this.

Does using LIBTOOL only effect the person trying to build a package from
source? Meaning, does it behave the same way as autoconf and automake? I
plan on installing libtool to develop the library. Then when I make a
release (make dist), the user will not have to have libtool installed, 
right? Currently my users do not need autoconf or automake installed to
build a dist that I have released.

Are there any disadvantages from switching to AC_PROG_LIBTOOL from

Also, when using AC_PROG_LIBTOOL, is there an easy way to force the
default behavior of building libraries to be static from within the file?

Bob Rossi

reply via email to

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