<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Christopher,</p>
    <p>CPLFindFile() calls CPLFinderInit() which issues
      CPLGetConfigOption( "GDAL_DATA", nullptr). But CPLFinderInit()
      runs once per-thread. So a potential theory for what you observe
      would be that something runs CPLFindFile() before you call
      CPLSetConfigOption("GDAL_DATA", ...). Setting breakpoint on
      CPLFinderInit and CPLSetConfigOption should confirm if this is
      what actually happens</p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 24/08/2021 à 23:17, Christopher
      Corbell a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP2bJPwrUMBQYSuxwDoC_a6xGbyy1WR=mKkd=etMnNKY10-OeA@mail.gmail.com">
      <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">(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"</pre>
        </div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Christopher</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>