Opened 8 years ago

Closed 7 years ago

#5490 closed enhancement (invalid)

GDAL must check driver version while loading from GDAL_DRIVER_PATH

Reported by: bishop Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: svn-trunk
Severity: normal Keywords:
Cc:

Description

Just according to global changes by RFC46 it worth to add functionality to prevent loading by gdal drivers from GDAL_DRIVER_PATH that linked with other gdal version. Proposed solutions:

  1. GDAL must add to GDAL_DRIVER_PATH current gdal version (i.e. GDAL_DRIVER_PATH/1.11/)
  1. Add some method (i.e. GetGDALDriverVer()) that any driver should support. If method is absent - the version is incompatible
  1. Drop global env support for GDAL_DRIVER_PATH - this is responsible of the developer to set right path for GDAL_DRIVER_PATH in the program via SetConfigOption? or --config key

Change History (5)

comment:1 Changed 7 years ago by Even Rouault

I'm not sure any of the proposed solution is needed. I'd note that solution 2 is somehow equivalent to the GDAL_CHECK_VERSION macro used in drivers that can be compiled as plugins

    if (! GDAL_CHECK_VERSION("MrSID driver"))
        return;

comment:2 Changed 7 years ago by bishop

I don't understand how this can help in situation there i.e gdal 2.0 loading the driver compiled with gdal 1.6 following the environment variable GDAL_DRIVER_PATH. In such case the new application crashes and old one - not. Also we have no garanties that developer add such check "if (! GDAL_CHECK_VERSION("MrSID driver"))" in his driver. I describe this situation in mailing list.

Yesterday I faced interesting problem on Win7 64 bit.
My program uses last gdal version 1.12. During start the error message
popuped in dialog that gdal v. 1.8 was not find and application closed.
I checked with dependency walker what were was no gdal 1.8 dependency in
application and all it dll's.
I found out that another program used the gdal 1.8  was installed on
that PC. And this program create env variable GDAL_DRIVER_PATH which
pointed on some non standard driver linked with gdal 1.8
My gdal 1.12 try to load this driver as GDAL_DRIVER_PATH was present and
crush as it was linked with gdal 1.8.
I solved it by setting CPLSetConfigOption("GDAL_DRIVER_PATH",
"disabled"); in my application, but this is not a good solution.
I think some version checking needed or something else. Anyhow I think
this is bug.

And this was not gdal driver from sources, but some custom one.

comment:3 Changed 7 years ago by Even Rouault

This seems a very particular cases where a program "polutes" the global environment instead of locally defining GDAL_DRIVER_PATH. And I guess that with the latest changes in the windows impl of CPLGetSymbol(), the dialog box wouldn't appear. See #5211, #5525

comment:4 Changed 7 years ago by bishop

Looks like a solution. Let me test this. If ok - I'll close the ticket.

comment:5 Changed 7 years ago by Even Rouault

Resolution: invalid
Status: newclosed

Closing this ticket. Reopen if needed

Note: See TracTickets for help on using tickets.