f2py-f90wrap v0.2.15 now leads to "Fatal Error: Cannot open module file xyz.mod’ for reading"

[jmp75]

I am not sure this is a f90wrap issue per se, but want to report it in case others bump into this issue. It may be a side effect of numpy f2py now relying on meson to build stuff.

Issue

I have a python wrapper in jmp75/air2stream at commit 02fc71 that builds fine in a conda environment that includes:

f90wrap                   0.2.13 
numpy                     1.26.0 
python                    3.9.16

I am trying to run the same wrapping build script into a new environment with:

python                    3.12.5
f90wrap                   0.2.15
numpy                     2.1.1
meson                     1.5.1  # now required by numpy-f2py it seems

This fails in the script regen_wrapper.sh at the step calling f2py-f90wrap:

[2/7] Compiling Fortran object _a2s.cpython-312-x86_64-linux-gnu.so.p/f90wrap_AIR2STREAM_MODULES.f90.o
FAILED: _a2s.cpython-312-x86_64-linux-gnu.so.p/f90wrap_AIR2STREAM_MODULES.f90.o 
gfortran -I_a2s.cpython-312-x86_64-linux-gnu.so.p -I. -I.. -I/home/abcdef/miniforge3/envs/a2s/lib/python3.12/site-packages/numpy/_core/include -I/home/abcdef/miniforge3/envs/a2s/lib/python3.12/site-packages/numpy/f2py/src -I/home/abcdef/miniforge3/envs/a2s/include/python3.12 -fvisibility=hidden -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -O3 -fPIC -J_a2s.cpython-312-x86_64-linux-gnu.so.p -o _a2s.cpython-312-x86_64-linux-gnu.so.p/f90wrap_AIR2STREAM_MODULES.f90.o -c ../f90wrap_AIR2STREAM_MODULES.f90
../f90wrap_AIR2STREAM_MODULES.f90:4:9:

    4 |     use commondata, only: commondata_n_par => n_par
      |         1
Fatal Error: Cannot open module file ‘commondata.mod’ for reading at (1): No such file or directory
compilation terminated.
[3/7] Compiling Fortran object _a2s.cpython-312-x86_64-linux-gnu.so.p/_a2s-f2pywrappers.f.o
[4/7] Compiling Fortran object _a2s.cpython-312-x86_64-linux-gnu.so.p/f90wrap_toplevel.f90.o
[5/7] Compiling C object _a2s.cpython-312-x86_64-linux-gnu.so.p/6a58a1f4e765b29ba60324f015623347fad0725c_.._.._f2py_src_fortranobject.c.o
[6/7] Compiling C object _a2s.cpython-312-x86_64-linux-gnu.so.p/_a2smodule.c.o
ninja: build stopped: subcommand failed.

[jmp75]

I can confirm this looks like a side effect of numpy f2py move to meson, which seems compulsory with python>=3.12. The following downgrade fixes my issue:

mamba uninstall meson
mamba install python=3.11

[jameskermode]

Thanks for reporting. f90wrap also depends on and uses Meson as its build system, so this should not directly be the reason for the problem, but it could very well be that the changes to f2py which has broken the monkey-patching done by f2py-f90wrap.

[krystophny]

I got the same problem and figured it is an upstream bug on numpy/numpy#27018 . My current workaround is to use python<3.12 and setuptools<74 where the distutils backend of f2py still works. This is no permanent solution. Since upstream is not active on the problem with the meson backend and extra objects and modules not parsed by f2py, a possibility would be to fix it here in f2py-f90wrap right away.

[krystophny]

Part of a workaround (faster than expected and also posted upstream):

export FFLAGS=-I`pwd`

This worked for me with python 3.12 with setuptools 75.6.0 to compile. However, the object code still cannot be found when loading the python module, maybe it is not linked.

[HaoZeke]

Part of a workaround (faster than expected and also posted upstream):

export FFLAGS=-I`pwd`

This worked for me with python 3.12 with setuptools 75.6.0 to compile. However, the object code still cannot be found when loading the python module, maybe it is not linked.

Almost, but the relevant -I$(pwd) needs to be passed to f2py so the meson.build also includes the directory, thus fixing the link error.