<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div><br></div><div><pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin-top:4px;margin-bottom:4px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;border-radius:4px"><font color="#000000">(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"</font></pre></div><div><br></div><div>Thanks,</div><div>Christopher</div></div>