[Gdal-dev] Reducing number of exported symbols

[Even Rouault]

I've created ticket 1810 (http://trac.osgeo.org/gdal/ticket/1810) and attached 
a patch for that.

On Sunday 09 September 2007 17:04:13 Frank Warmerdam wrote:
> Even,
>
> I am quite interested in this change.  My suggestions would be that for now
> (GDAL/OGR 1.5.0) we drive it by an optional configure switch defaulting to
> the old behavior, and for 1.6 we switch to defaulting to use the new
> behavior if we have an appropriate gcc.
>
> Even Rouault wrote:
> > I give it a try on my system. This required only another change in
> > shapefil.h that doesn't use CPL_DLL but SHPAPI_CALL that is equivalent.
> >
> > #ifndef SHPAPI_CALL
> > #  if defined(__GNUC__) && __GNUC__ >= 4
> > #    define SHPAPI_CALL     __attribute__ ((visibility("default")))
> > #    define SHPAPI_CALL1(x) __attribute__ ((visibility("default")))     x
> > #  else
> > #    define SHPAPI_CALL
> > #  endif
> > #endif
>
> Presumably we could pre-define SHPAPI_CALL in the makefile.
>
> > Result : only 3 442 symbols ! Roughly like on Windows :-)
> >
> > Another great benefit is that it should prevent subtle and annoying
> > problems when linking an executable with a GDAL library build with
> > internal libtiff/libpng/libjpeg/etc... and one of these libraries.Now
> > most of them have disappeared form libgdal.so. This may be becoming
> > necessary with new libtiff 4.0 that has become the internal GDAL libtiff,
> > whereas most *nix systems/distributios still uses 3.8.2. People will
> > probably want to use BigTIFF capabilities without messing up their system
> > libtiff. Mixing symbols from both versions is definitely not a good idea
> > as there has been ABI changes.
> > The case for internal libgeotiff is a bit different since it uses CPL_DLL
> > too in its header. So, symbols for internal libgeotiff are still
> > exported. We should fine a way to distinguish the case when it's built in
> > GDAL tree from when it's build standalone.
>
> We have a CPL_ODLL macro we use for APIs that would not normally be
> public, but that we sometimes want to export.  On windows this was
> introduced so that stuff like the libtiff and libgeotiff API could
> be exported optionally. I would suggest we aim to use it in a similar
> fashion with gcc.
>
> Best regards,