[GRASS-dev] Can I trust libtool?

[Glynn Clements]

marco.pasetti at alice.it wrote:

> I started to build on Windows (MSYS/MinGW) latest releases of GRASS
> required libraries (zlib, libpng, and so on...) and I thought everything
> was going well... but (occasionally) browsing /usr/lib dir I found NO
> dlls of what I built, only .a and .la libraries, while I found dlls in
> /usr/bin... I assumed that was due to libtool (what a °*_°!!), on
> how it creates and links libraries; because I don't know so much about
> this matter, I then preferred to go on the safe way and use Paul's
> prebuilt libs; the same is for GDAL (so, I must use 1.4.1 againt latest
> 1.5.0); ...but, at the same time I'm building expat, gsl and geos using
> libtool!!! what a mess!!
>  
> If you tell me that I can trust the way libtool manages libraries and
> linking (I use latest MinGW release), I could restart all (how much time
> spent...!) and rebuild using latest libraries (for png, proj, gdal...
> and so on... and trying to add also tiff and jpeg support, and,
> probably, ffmpeg).

Windows doesn't have a separate path variable for DLLs, like
LD_LIBRARY_PATH on Linux. DLLs are located using a combination of
PATH, various system directories, registry entries, and the directory
containing the executable.

Consequently, Windows builds normally put DLLs in the "bin" directory
so that they will be found without needing additional configuration. 
The "lib" directory is normally reserved for static libraries
(including import libraries for DLLs).

FWIW, GRASS itself doesn't use libtool. Also, because it already needs
to set a large number of environment variables at startup, it puts
DLLs into the lib directory and adds the lib directory to the PATH
setting.

-- 
Glynn Clements <glynn at gclements.plus.com>