[gdal-dev] CPLFindFile not honoring CPLSetConfigOption

[Christopher Corbell]

I'm tracking down a bug with WFS data import in our app and it seems like
the cause is a call to CPLFindFile returning NULL, looking for a
gmlasconf.xml file that should be in the gdal share directory.

This is a Mac universal binary app that embeds GDAL as a dylib and also
includes the share files, so we use CPLSetConfigOption("GDAL_DATA", ...) to
configure the CPL. So we don't rely on any absolute install/build paths or
on the end-user installing their own GDAL. This worked previously but we
recently updated to GDAL 3.3.1.

The WFS import fails when CPLFindFile returns NULL on attempt to read that
config file, but the bug does not occur on my workstation, where this copy
of GDAL was built. It turns out this is because CPLFindFile will return the
original location of the GDAL build/install share directory (which still
exists on my system).

Can anyone offer a theory why CPLFindFile might ignore the gdal data path
and only look in the absolute install path set when GDAL was built? Here's
some debugger output showing how these functions point to two different
directories at runtime:

(lldb) po (const char*) CPLGetConfigOption("GDAL_DATA")
"/Users/ccorbell/Development/working/ccorbell_27x_MBP/IP
Source/Plug-ins/Common/Data/GIS/gdal/"

(lldb) po (const char*) CPLFindFile("gdal", "gmlasconf.xml")
"/Users/ccorbell/Development/working/ccorbell_27x_MBP/AppSource/ThirdPartySource/GDAL/config/gdal-3.3.1-x86_64/share/gdal/gmlasconf.xml"


Thanks,
Christopher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210824/11f816ca/attachment.html>