libtool
[Top][All Lists]
Advanced

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

RE: Using libtool 2.0 in autoconf tests


From: Peter Ekberg
Subject: RE: Using libtool 2.0 in autoconf tests
Date: Thu, 18 Nov 2004 14:22:28 +0100

Sander Niemeijer wrote:
> Hi,
> 
> I have send this question to the list about a month ago, but
> unfortunately, there hasn't been an answer yet, and the release of
> libtool 2.0 is not that far away (right?).
> 
> <http://lists.gnu.org/archive/html/libtool/2004-10/msg00219.html>
> <http://lists.gnu.org/archive/html/libtool/2004-10/msg00222.html>
> 
> I have some self written autoconf tests that check for linking shared
> libraries against some specific other libraries (these other libraries
> should be available as shared libraries or we might have a
> PIC problem.
> That is what my tests checks for). For this I had to create a variant
> of the AC_LINK_IFELSE macro that doesn't use CC/LD but the libtool
> script to perform the compilation/linking. With libtool 1.5.x the
> libtool script was nicely available, but with libtool 2.0 the libtool
> script is only available after AC_OUTPUT is handled. So _after_ all
> autoconf tests are performed. 
> 
> How can I still perform my autoconf tests when libtool 2.0 comes out?
> Is there some way to generate the libtool 2.0 script before AC_OUTPUT?
> Is it otherwise possible to use some configure script variables in
> combination with ltmain.sh to perform my shared library specific
> AC_LINK_IFELSE check? 
> 
>  From a general perspective I also find it rather strange having the
> libtool script only available after AC_OUTPUT. It is like
> having CC (or
> any other necessary compiler/linker) only available after AC_OUTPUT.
> Since I am doing my compilation and linking with libtool, I
> would think
> it only logical that I would also be able to perform some autoconf
> tests with my compilation/linking tool.

We have the same issue (for different reasons) in the GGI family of
libraries and I was eagerly waiting for an answer to your question.
I had forgotten about it though. I'm now writing to mention that
our workaround is an horrible hack that calls a second configure
script from inside the real configure script. The second configure
script (called genlibtool) has the sole purpose of generating the
libtool script. This is an horrible hack since it currently does
not solve all troubles (only some) resulting from two instances of
configure (albeit with different names) being active at the same
time. It also generates the libtool script twice which is a waste.

So, to sum it up, a possible horrible workaround and you are not
alone. Hope that at least makes you feel better...

http://www.ggi-project.org should have links to the source code if
you want to have a closer look at our "solution". The current
release candidate does not use the libtool-2-0 branch, so you have
to get the cvs version from sourceforge to see it.

Cheers,
Peter




reply via email to

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