[gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ?

Even Rouault even.rouault at spatialys.com
Sat May 6 10:35:18 PDT 2017

On samedi 6 mai 2017 17:04:33 CEST Ivan Lucena wrote:
> -1
> We have the options to build drivers against static and dynamic libraries of
> its SDKs, like HDF4,5 and openjpeg for example, using the same
> "--with-driver-name"
> Why not keep that same option for proj4?

I think you are confusing things. For a good reason since the --with-static-proj4 name is 
confusing. --with-static-proj4 can link against libproj.a or libproj.so depending on which is 
available, which is classic build time linking. My suggestion is to keep this as the only option 
to use proj.4, and rename it --with-proj4 for more clarity and consistency

When this option is not specified, proj4 is optionaly loaded through dlopen()/LoadLibrary(), 
which is runtime linking and what I'm proposing to drop for simplicity.

HDF4, 5, openjpeg are only supported through build time linking. 

> --with-proj4=<static or dynamic>-library-path
> I have projects where I let user to decide if they want to download and
> install proj4 while using GDAL and I would prefer to keep that option.

Well, that seem to be a rather particular use case. Given the small size of libproj regarding 
libgdal, you could always build against proj.

After my cleanup and removal of pre-4.8 support, ogrct.cpp is now down to 1110 lines 
against 1311 before, and much easier to follow. And that save testing behaviour in --with-
static-proj4 and --without-static-proj4 cases

> Maybe with a compiler option we can basically "remove" the dynamic load when
> static linked proj4 was used.

That's already the case. If currently you use --with-static-proj4, dynamic loading at runtime is 

Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170506/eb4c6f54/attachment.html>

More information about the gdal-dev mailing list