[mapserver-dev] libtool usage

[thomas bonfort]

On Mon, Dec 19, 2011 at 18:21, Even Rouault
<even.rouault at mines-paris.org> wrote:
>
>> >>
>> >> Maybe Frank or others involved in the GDAL libtool build support could
>> >> share their experience?
>>
>> I would very much like to get the feedback of Frank or Even on this, yes.
>>
>
> I don't consider myself as an authoritative voice as far as build systems are
> concerned and don't remember to have ever touched this part of GDAL. I almost
> always use --without-libtool builds of GDAL, mainly because it is faster than a
> libtool build (due to the absence of invocation of the libtool wrapper) ;-) But,
> I don't recall any particular problem with libool builds of GDAL when I have
> used them, but as I said, I almost never use them.
libtool by default builds each object file twice, once with -fPIC and
once without, in order to be able to build shared and static
binaries/libraries in the subsequent steps. configuring the source
tree with --disable-static or --disabled-shared should bring the
compile times down to roughly the same as the non libtool builds, I
would imagine.

>
> All I can tell is that my last expericence with libtool was yesterday, and not a
> good one. I tried to build a svn head version of GEOS yesterday on a HPPA Debian
> machine. I must say that this machine didn't have any of the autoconf, automake
> and libtool packages installed in /usr/bin, so I had to build them manually from
> sources. And I had an issue during the build of geos, due to a mix between
> libtool 2.4 and libtool 2.4.2 (the one I built at hand). I finally managed to
> solve it by reverting to libtool 2.4 and relaunching the ./autogen.sh
> ./configure process again.

trunk checkouts might be somewhat painfull on some occasions, and I
agree that the steps to rerun libtoolize, aclocal and autoconf (we do
not rely on automake) should be documented in the source tree. For
releases this should never be an issue as all the build files will be
built shell scripts (with no need for the autoconf toolchain to be
installed).

>
> I also somehow remember having problems with .la files generated by libtool that
> had some bad content and that I had to manually edit. But I don't remember which
> package it was. It is possible that it was in a context where mingw was
> involved, not sure however.
>
> Sorry for not being more precise...

thanks for the feedback Even,

regards,
thomas