<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Andrew,</p>
<p>interestingly adding the debug traces I suggested to you to the
GDAL CI MacOS 14 build witch no longer worked turns out to reveal
the exact same issue as yours! (funny that I didn't even consider
doing that myself ! interesting case where helping others actually
is helping oneself :-)) _gdal.cpython-312-darwin.so was also
linking against libgdal.so.34 (GDAL 3.8.5) instead of
libgdal.so.35 (libgdal 3.10dev). The reason is that this CI
configuration uses conda-forge to install dependencies, and it
accidentally installed libgdal itself, instead of just its
dependencies (it add a "conda install --only-deps libgdal
libgdal-arrow-parquet" line, but I missed that libgdal *is* a
dependency of libgdal-arrow-parquet... )<br>
</p>
<p>Looking at the compilation log, I see:<br>
</p>
<p>arm64-apple-darwin20.0.0-clang++ -bundle -undefined
dynamic_lookup -Wl,-rpath,/Users/runner/miniconda3/envs/test/lib
-L/Users/runner/miniconda3/envs/test/lib
-Wl,-rpath,/Users/runner/miniconda3/envs/test/lib
-L/Users/runner/miniconda3/envs/test/lib
-Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs
-Wl,-rpath,/Users/runner/miniconda3/envs/test/lib
-L/Users/runner/miniconda3/envs/test/lib -ftree-vectorize -fPIC
-fstack-protector-strong -O2 -pipe -isystem
/Users/runner/miniconda3/envs/test/include -D_FORTIFY_SOURCE=2
-isystem /Users/runner/miniconda3/envs/test/include
build/temp.macosx-11.0-arm64-cpython-312/extensions/gdal_wrap.o
-L/Users/runner/work/gdal/gdal/build -lgdal -o
build/lib.macosx-11.0-arm64-cpython-312/osgeo/_gdal.cpython-312-darwin.so</p>
<p>So something in the Python extension building logic (conda
customizations?) adds this
-L/Users/runner/miniconda3/envs/test/lib where the "libgdal" from
conda-forge is found, which apparently takes precedence over the "-L/Users/runner/work/gdal/gdal/build
-lgdal" towards the end of the line, which is the bit that links
against the libgdal of the build tree.</p>
<p>For my CI case removing libgdal from the installed conda-forge
packages fixed the issue, but it would be nice if we could
avoid/detect the issue in the first place. If so, that would
likely be some magic to add into swig/python/setup.py.in. It might
be tricky to do so though. Like detecting -Larg in the linking
options and looking for a libgdal.so/dylib in them... ? Yuck. Or
perhaps do some postprocessing check that the resulting extension
.so links against the expected libgdal?<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 30/04/2024 à 17:41, Andrew Bell a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CACJ51z1H_OYPr1SDELa_-KXk8RRL5peok1+n4uy-dNEAAB3xjA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Tue, Apr 30, 2024 at 9:18 AM Even Rouault <<a
href="mailto:even.rouault@spatialys.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
wrote:<br>
<br>
Even,</div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Also try in a Python interpreter "from osgeo import
gdal" to see if the exception is more verbose. If your
GDAL lib links against libraries that are not in the
default library search path, GDAL command line utilities
might still be able to find them, but loading libgdal
through the Python bindings might fail (at least that
happens to me on Linux, cf <a
href="https://github.com/OSGeo/gdal/pull/9783"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/OSGeo/gdal/pull/9783</a>)<br>
</p>
</div>
</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>Also try otool -L on libgdal.dylib and on _<a
href="http://gdal.cpython-312-darwin.so" target="_blank"
moz-do-not-send="true">gdal.cpython-312-darwin.so</a></p>
</blockquote>
<div>This was indeed the issue. I didn't think there was a
version of GDAL in my environment, but it must have gotten
in by error at some point. When the SWIG library _gdal...so
was created, a dependency was created for the system-located
library (version 34) rather than the one in the build
(version 35). I'd have to do more research to figure out how
to rectify this, if desired.<br>
<br>
Thanks for your help. The python failure message wasn't too
helpful on its own.<br>
<br>
</div>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Andrew Bell<br>
<a href="mailto:andrew.bell.ia@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">andrew.bell.ia@gmail.com</a></div>
</div>
</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>