[Top][All Lists]
[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