Hi, this feels like a huge can of worms, but might aswell put it here in the open..
/usr/local/lib/python3.8/_sysconfigdata__openbsd7_.py sets various vars (LDFLAGS, BLDSHARED, LDSHARED, PY_CORE_LDFLAGS, PY_LDFLAGS) that contains '-L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/' which feels .. wrong. it seems (some?) of those vars are used by setuptools, eg /usr/local/lib/python3.8/site-packages/setuptools/command/build_ext.py and /usr/local/lib/python3.8/site-packages/setuptools/_distutils/sysconfig.py and that can lead to issues when building things outside of ports. In my case, i spotted it when building gdal from git master, where the python extensions are linked with the wrong library because of the ordering of flags on the build line: cc -pthread -shared -fPIC -L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12 -L/usr/local/lib/ build/temp.openbsd-7.0-amd64-3.8/extensions/gdalconst_wrap.o -L/usr/obj/gdal -L/usr/local/lib -lgdal -o build/lib.openbsd-7.0-amd64-3.8/osgeo/_gdalconst.cpython-38.so the first part of the build line is the value of the LDSHARED/BLDSHARED variable. cf https://github.com/OSGeo/gdal/pull/4663#issuecomment-954950215 for my initial findings. with that build line, _gdalconst.cpython-38.so ends up linked with /usr/local/lib/libgdal* instead of /usr/obj/gdal/libgdal* which leads to symbols mismatch between different versions of the libs (3.3.3 vs master) if i remove the -L paths from LDSHARED/BLDSHARED in /usr/local/lib/python3.8/_sysconfigdata__openbsd7_.py the build line ends up being cc -pthread -shared -fPIC build/temp.openbsd-7.0-amd64-3.8/extensions/gdalconst_wrap.o -L/usr/obj/gdal -L/usr/local/lib -lgdal -o build/lib.openbsd-7.0-amd64-3.8/osgeo/_gdalconst.cpython-38.so and the python extension is linked with the *right* gdal lib (as confirmed by objdump -p) : i didnt manage to find where the extra -L/usr/local/lib comes from but since it's after -L/usr/obj/gdal it seems llvm takes the first lib it founds. ive looked at a python linux install, and the _sysconfigdata__x86_64-linux-gnu.py file contains no -L flags pointing to weird paths...but everything is installed in the default /usr/lib search path of course. i dunno if something should be fixed in the python build system (is it *necessary* to point at /usr/local/lib for libpython3.8.so ?), but i think there's something definitely wrong somewhere. That probably accounts for many failures i remember seeing building python updates when the previous version was installed systemwide, and taking precedence over the just-newly-built lib/extension. Landry
