I am noticing this behaviour in our CI since a few days, and given the changelog notes about RPATH handling, I assume this might be a regression (or intentional change in behaviour) with the latest 0.22.0 release.
I also see there is an issue open about expectations in general for various cases (#903), but since I am not familiar enough with this to judge if this belongs there, opening a separate issue (cc @rgommers)
Trying to reproduce locally with a more minimal example, it seems to be triggered by having compilers installed in the conda env or not. The specific case is installing shapely from source on Linux (ubuntu), where shapely uses meson-python for its build system now and depends on one "system" library (GEOS). What I observe:
- If the conda env does not contain compilers (but just
libgcc which gets included through python/cython, I think), meson picks up the system gcc, finds the GEOS dependency just fine during build-time, but does not find it at runtime.
- If the conda env does include compilers, meson picks up the conda env gcc, and then shapely finds the conda GEOS lib at runtime just fine.
Checking the resulting .so files for the python extension modules, I do see that in the first case the RUNPATH is not set, while it is in the second case (to the conda env's /lib/ directory).
When I force an older version of meson-python for the first bullet point case, it also works fine.
Now, if one is installing a package from source that requires a compiler in a conda env, it might certainly be good practice to use compilers from conda as well, and maybe this only worked "by accident" before. But since this worked before, and it gives confusing results now (since building works just fine, and with conda you don't consider this as a "custom install" of the geos dependency), reporting here.
On the geopandas CI where we are installing shapely from source, we did include cython in the conda env (maybe with the assumption that this would also install compilers? I don't remember, we have been doing that for many years), but not actually compilers. This can of course easily be fixed, but installing cython also (accidentally) avoided running into mesonbuild/meson#15740
The minimal CI workflow that reproduces the issue:
$ mamba create -n test-meson-cy python=3.13 geos pkg-config cython
$ mamba activate test-meson-cy
(test-meson-cy) $ python -m pip install git+https://github.com/shapely/shapely.git@main -v
...
Successfully installed Cython-3.3.0 meson-1.12.1 meson-python-0.22.0 numpy-2.5.3 packaging-26.3 pyproject-metadata-0.12.1
...
Version: 1.12.1
Source dir: /tmp/pip-req-build-b9h4dfq7
Build dir: /tmp/pip-req-build-b9h4dfq7/.mesonpy-f634h_cm
Build type: native build
Program python found: YES
Project name: shapely
Project version: 2.2.0rc1+1.ge044b13
C compiler for the host machine: cc (gcc 11.4.0 "cc (Ubuntu 11.4.0-1ubuntu1~22.04.3) 11.4.0")
C linker for the host machine: cc ld.bfd 2.38
Cython compiler for the host machine: cython (cython 3.3.0)
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-cast-function-type: YES
Compiler for C supports arguments -Wno-unused-parameter: YES
Program python found: YES (/home/joris/conda/envs/test-meson-cy/bin/python)
Run-time dependency geos found: YES 3.14.1
numpy-config found: YES (/tmp/pip-build-env-qy0p3i6y/overlay/bin/numpy-config) 2.5.3
Run-time dependency numpy found: YES 2.5.3
Found pkg-config: YES (/home/joris/conda/envs/test-meson-cy/bin/pkg-config) 0.29.2
Run-time dependency python found: YES 3.13
Build targets in project: 4
shapely 2.2.0rc1+1.ge044b13
...
Successfully installed numpy-2.5.3 shapely-2.2.0rc1+1.ge044b13
(test-meson-cy) $ python -c "import shapely; print(shapely.__version__)"
...
File "/home/joris/conda/envs/test-meson-cy/lib/python3.13/site-packages/shapely/__init__.py", line 20, in <module>
from shapely.lib import GEOSException
ImportError: libgeos_c.so.1: cannot open shared object file: No such file or directory
(test-meson-cy) $ ldd /home/joris/conda/envs/test-meson-cy/lib/python3.13/site-packages/shapely/lib.cpython-313-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffd2b8d4000)
libgeos_c.so.1 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdb93e00000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdb940e2000)
The above installs cython in the env (which does not actually install a compiler in the env?), and based on the logs above, meson actually picks up the system (Ubuntu) C compiler. However, what I initially tried first locally to reproduce was to include compilers in the env. Doing that work fine, and the equivalent logs:
$ mamba create -n test-meson python=3.13 geos pkg-config compilers
$ mamba activate test-meson
(test-meson) $ python -m pip install git+https://github.com/shapely/shapely.git@main -v
...
Successfully installed Cython-3.3.0 meson-1.12.1 meson-python-0.22.0 numpy-2.5.3 packaging-26.3 pyproject-metadata-0.12.1
...
The Meson build system
Version: 1.12.1
Source dir: /tmp/pip-req-build-l88btzqu
Build dir: /tmp/pip-req-build-l88btzqu/.mesonpy-2n5hyvjs
Build type: native build
Program python found: YES
Project name: shapely
Project version: 2.2.0rc1+1.ge044b13
C compiler for the host machine: /home/joris/conda/envs/test-meson/bin/x86_64-conda-linux-gnu-cc (gcc 14.3.0 "x86_64-conda-linux-gnu-cc (conda-forge gcc 14.3.0-19) 14.3.0")
C linker for the host machine: /home/joris/conda/envs/test-meson/bin/x86_64-conda-linux-gnu-cc ld.bfd 2.45.1
Cython compiler for the host machine: cython (cython 3.3.0)
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-cast-function-type: YES
Compiler for C supports arguments -Wno-unused-parameter: YES
Program python found: YES (/home/joris/conda/envs/test-meson/bin/python)
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency geos found: NO (tried cmake)
Run-time dependency geos found: YES 3.14.1
numpy-config found: YES (/tmp/pip-build-env-l5rdrf5r/overlay/bin/numpy-config) 2.5.3
Run-time dependency numpy found: YES 2.5.3
Found pkg-config: YES (/home/joris/conda/envs/test-meson/bin/pkg-config) 0.29.2
Run-time dependency python found: YES 3.13
Build targets in project: 4
shapely 2.2.0rc1+1.ge044b13
...
Successfully installed numpy-2.5.3 shapely-2.2.0rc1+1.ge044b13
(test-meson) $ python -c "import shapely; print(shapely.__version__)"
2.2.0rc1+1.ge044b13
(test-meson) $ ldd /home/joris/conda/envs/test-meson/lib/python3.13/site-packages/shapely/lib.cpython-313-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007fff52550000)
libgeos_c.so.1 => /home/joris/conda/envs/test-meson/lib/libgeos_c.so.1 (0x00007fb1b344a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb1b3200000)
libgeos.so.3.14.1 => /home/joris/conda/envs/test-meson/lib/./libgeos.so.3.14.1 (0x00007fb1b2e00000)
libstdc++.so.6 => /home/joris/conda/envs/test-meson/lib/./libstdc++.so.6 (0x00007fb1b2a00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb1b2d19000)
libgcc_s.so.1 => /home/joris/conda/envs/test-meson/lib/./libgcc_s.so.1 (0x00007fb1b31d3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb1b34de000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb1b3430000)
I am noticing this behaviour in our CI since a few days, and given the changelog notes about RPATH handling, I assume this might be a regression (or intentional change in behaviour) with the latest 0.22.0 release.
I also see there is an issue open about expectations in general for various cases (#903), but since I am not familiar enough with this to judge if this belongs there, opening a separate issue (cc @rgommers)
Trying to reproduce locally with a more minimal example, it seems to be triggered by having
compilersinstalled in the conda env or not. The specific case is installing shapely from source on Linux (ubuntu), where shapely uses meson-python for its build system now and depends on one "system" library (GEOS). What I observe:libgccwhich gets included through python/cython, I think), meson picks up the system gcc, finds the GEOS dependency just fine during build-time, but does not find it at runtime.Checking the resulting .so files for the python extension modules, I do see that in the first case the RUNPATH is not set, while it is in the second case (to the conda env's
/lib/directory).When I force an older version of meson-python for the first bullet point case, it also works fine.
Now, if one is installing a package from source that requires a compiler in a conda env, it might certainly be good practice to use compilers from conda as well, and maybe this only worked "by accident" before. But since this worked before, and it gives confusing results now (since building works just fine, and with conda you don't consider this as a "custom install" of the geos dependency), reporting here.
On the geopandas CI where we are installing shapely from source, we did include
cythonin the conda env (maybe with the assumption that this would also install compilers? I don't remember, we have been doing that for many years), but not actually compilers. This can of course easily be fixed, but installing cython also (accidentally) avoided running into mesonbuild/meson#15740The minimal CI workflow that reproduces the issue:
The above installs cython in the env (which does not actually install a compiler in the env?), and based on the logs above, meson actually picks up the system (Ubuntu) C compiler. However, what I initially tried first locally to reproduce was to include
compilersin the env. Doing that work fine, and the equivalent logs: