libtool
[Top][All Lists]
Advanced

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

Re: LT_INIT pic-only not setting --with-pic


From: Ralf Wildenhues
Subject: Re: LT_INIT pic-only not setting --with-pic
Date: Mon, 11 Oct 2010 19:50:59 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Luke,

* Luke Mewburn wrote on Mon, Oct 11, 2010 at 05:52:16AM CEST:
> I'm using libtool (and the other autotools) to build an installed
> static library (which I don't want it as a shared library),
> which I link into various other applications.
> 
> I sometimes need to link this static library into a dynamic
> object, such as a python module, and so we need the static
> library compiled as PIC.

You could make it a convenience archive, and install it with a manually
written install rule (both the libconv.la and libconv.a).

> Recently, I started getting libtool failures trying to build
> the shared python module, complaining about the missing PIC
> support.  I had made a few changes to our build infrastructure,
> including:
>  - upgrade from libtool 2.2.10 to libtool 2.4
>  - explicit use of LT_INIT in configure.ac
>  - conversion from use of foo_LDADD = -static in Makefile.am
>    to LT_INIT([disable-shared])
> and one of these stopped the PIC compilation of the objects.
> I speculate it was the use of disable-shared versus the previous
> behaviour where I was getting implicit PIC support in the normal
> build.
> 
> As a solution, I tried LT_INIT([disable-shared pic-only]),
> but that did not seem to set --with-pic as I expected.
> 
> My current workaround is to explicitly invoke configure --with-pic
> in the package build framework.
> 
> Is LT_INIT([disable-shared pic-only]) not setting --with-pic
> a bug in libtool, or my misunderstanding of its purpose?

I think that's a semantic difference in the LT_INIT interface vs. the
previous one.  Can you show your old code, or a reduced version of it?

Thanks,
Ralf



reply via email to

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