Quantcast

Issues with static GDAL library and ESRI Shapefiles

classic Classic list List threaded Threaded
3 messages Options
nbmont nbmont
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Issues with static GDAL library and ESRI Shapefiles

Hi all,


I suspect this is a known problem, but I wanted to get a sanity check:


I am linking GDAL statically -- we have an existing build that I am trying to use so I don't have to carry around multiple versions in my application.

I'm running into some problems with plugins (actually any library outside osgEarth) that use GDAL.  Specifically, it's unable to find any of the GDAL drivers -- when FeatureSourceOGR.cpp tries to call

                _ogrDriverHandle = OGRGetDriverByName( driverName.c_str() );

... it returns a null handle.

I traced this problem back to the fact we only call

    // set up GDAL and OGR.
    OGRRegisterAll();
    GDALAllRegister();

... from Registry.cpp in osgEarth.dll.  Since I'm linking GDAL statically, each DLL has its own copy of GDAL's globals, meaning osgEarth.dll has the GDAL drivers loaded but the other DLL's do not.


So it seems the only way that it's even possible for the OGR plugin to work correctly is to build GDAL to a DLL instead of a static library.  The only reason I thought osgEarth might have meant to support a static GDAL is that there are options in the CMakeLists for it.  As far as I know the only way to make this configuration to work would be to move all GDAL calls into osgEarth, wrap them, and have all the other libraries and plugins go through the wrapped interface...

Thoughts?

Thanks,
Nathan
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with static GDAL library and ESRI Shapefiles

Hi Nathan,

The CMake options for static GDAL are probably vestigial and don't actually work.  We've only ever tested against a dynamic GDAL.  Would it be possible to just call the OGRRegisterAll and GDALAllRegister functions from the OGR plugin as well?  

Jason

On Mon, Feb 13, 2017 at 10:47 AM nbmont [via osgEarth] <[hidden email]> wrote:
Hi all,


I suspect this is a known problem, but I wanted to get a sanity check:


I am linking GDAL statically -- we have an existing build that I am trying to use so I don't have to carry around multiple versions in my application.

I'm running into some problems with plugins (actually any library outside osgEarth) that use GDAL.  Specifically, it's unable to find any of the GDAL drivers -- when FeatureSourceOGR.cpp tries to call

                _ogrDriverHandle = OGRGetDriverByName( driverName.c_str() );

... it returns a null handle.

I traced this problem back to the fact we only call

    // set up GDAL and OGR.
    OGRRegisterAll();
    GDALAllRegister();

... from Registry.cpp in osgEarth.dll.  Since I'm linking GDAL statically, each DLL has its own copy of GDAL's globals, meaning osgEarth.dll has the GDAL drivers loaded but the other DLL's do not.


So it seems the only way that it's even possible for the OGR plugin to work correctly is to build GDAL to a DLL instead of a static library.  The only reason I thought osgEarth might have meant to support a static GDAL is that there are options in the CMakeLists for it.  As far as I know the only way to make this configuration to work would be to move all GDAL calls into osgEarth, wrap them, and have all the other libraries and plugins go through the wrapped interface...

Thoughts?

Thanks,
Nathan


If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/Issues-with-static-GDAL-library-and-ESRI-Shapefiles-tp7590477.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
nbmont nbmont
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Issues with static GDAL library and ESRI Shapefiles

> The CMake options for static GDAL are probably vestigial and don't actually work.  We've only ever tested against a dynamic GDAL.

Thanks Jason, that's exactly the info I was looking for.

> Would it be possible to just call the OGRRegisterAll and GDALAllRegister functions from the OGR plugin as well?

I have no idea if that will work, but it's certainly easy to try.  I'll let you know how it goes :)

-Nathan
Loading...