This particular issue is because -L and -l are not supported by the meson backend now, and should be set via environment variables as discussed on the migrating to meson page.

Since the log shows 1.26.2 I think changing the call should be enough. Please reopen if not.

Thanks, I'll try it. Is there a clean way to write the call so that it also covers the Python <3.11/distutils case? I guess LDFLAGS="-L${CMAKE_BINARY_DIR}/src" LIBS="-lbufr_4" f2py --verbose -c _bufrlib.pyf -m _bufrlib -L${CMAKE_BINARY_DIR}/src -lbufr_4 might work but it'd be nice to avoid the redundancy if possible.

Thanks, I'll try it. Is there a clean way to write the call so that it also covers the Python <3.11/distutils case? I guess LDFLAGS="-L${CMAKE_BINARY_DIR}/src" LIBS="-lbufr_4" f2py --verbose -c _bufrlib.pyf -m _bufrlib -L${CMAKE_BINARY_DIR}/src -lbufr_4 might work but it'd be nice to avoid the redundancy if possible.

I would personally drop -L and -l completely and pass --backend meson instead, but even otherwise, I thought distutils also respects environment variables..

If this is a dependency which can be discovered by meson it is worth trying --dep bufr_4 or --dep bufr as well.

I can't seem to get it to work either way. In the case of -L/-l (LDFLAGS="-L/path/to/src" LIBS="-lbufr_4" f2py --verbose -c /path/to/_bufrlib.pyf -m _bufrlib --backend meson; also tried putting everything under LIBS) it doesn't seem to have any effect. There's no cmake or pkgconfig info at this step in the build process (this is under a cmake project, and the python module is built on top of the main library, so we haven't run 'make install' yet), so I'm unable to add a bufr target for meson to use.

Could you try with --build-dir blah and test if:

cd blah
# export LDFLAGS and LIBS here
meson compile -C bbdir

works? Does it work on Linux? (should be the same though)

EDIT: I'll check the upstream source out too.

Thankfully I've been able to reproduce the issue on Linux, which is what my PC uses, and the same thing is happening (so that's good, I guess). I ran with --build-dir etc. and got the same result. I ran meson compile --verbose ... and found that the -L flag was getting incorporated, but not the -l one. I can get around it by putting the -l in LDFLAGS instead of LIBS (or by just setting LDFLAGS to use the path to the library itself).

The problem now is that when I run nm _bufrlib.cpython-312-x86_64-linux-gnu.so, I can see that the various functions are getting populated, but my python module still doesn't load, e.g., AttributeError: module '_bufrlib' has no attribute 'bvers', yet I can see that bvers() is defined in the .so file. For fun, if I delete that reference in my __init__.py, the next problem that pops up is AttributeError: module '_bufrlib' has no attribute 'datelen', and in that case, I can see that there is no datelen() defined in the .so file, even though it is defined both in _bufrlib.pyf and libbufr_4.a.

Thankfully I've been able to reproduce the issue on Linux, which is what my PC uses, and the same thing is happening (so that's good, I guess). I ran with --build-dir etc. and got the same result. I ran meson compile --verbose ... and found that the -L flag was getting incorporated, but not the -l one. I can get around it by putting the -l in LDFLAGS instead of LIBS (or by just setting LDFLAGS to use the path to the library itself).

The problem now is that when I run nm _bufrlib.cpython-312-x86_64-linux-gnu.so, I can see that the various functions are getting populated, but my python module still doesn't load, e.g., AttributeError: module '_bufrlib' has no attribute 'bvers', yet I can see that bvers() is defined in the .so file. For fun, if I delete that reference in my init.py, the next problem that pops up is AttributeError: module '_bufrlib' has no attribute 'datelen', and in that case, I can see that there is no datelen() defined in the .so file, even though it is defined both in _bufrlib.pyf and libbufr_4.a.

Could you add steps to reproduce this? I'm reopening this since it seems to be an f2py build thing..

Here's the command my cmake/make is running:

/usr/bin/cmake -E env LDFLAGS=-L/n/NCEPLIBS_CI_Updates_Nov2023/NCEPLIBS-bufr/build/src\ -lbufr_4 /opt/spack_nov23/var/spack/environments/python-312-gcc-11/install/linux-centos8-zen3/gcc-11.2.1/python-3.12.0-khbplgh6i6jpf7i6znui44zdubchaw23/bin/f2py --verbose -c /n/NCEPLIBS_CI_Updates_Nov2023/NCEPLIBS-bufr/python/_bufrlib.pyf -m _bufrlib --backend meson

Let me know if there's more I can provide; it might take a while to distill it down to a simplified test case but I can do that if needed. As far as what I'm running:

# (python 3.12 and meson 1.2.2 installed through spack; numpy 1.26.2 installed through pip)
git clone https://github.com/AlexanderRichert-NOAA/NCEPLIBS-bufr -b ci_updates_nov2023
cd NCEPLIBS-bufr/
mkdir build && cd build/
cmake .. -DENABLE_PYTHON=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=$PWD/install
make -j2
export PYTHONPATH=$(realpath python):$PYTHONPATH
python -c "import ncepbufr"

Result:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/dev/shm/NCEPLIBS-bufr/build/python/ncepbufr/__init__.py", line 9, in <module>
    __bufrlib_version__ = _bufrlib.bvers().rstrip()
                          ^^^^^^^^^^^^^^
AttributeError: module '_bufrlib' has no attribute 'bvers'

Let me know if there's more I can provide; it might take a while to distill it down to a simplified test case but I can do that if needed. As far as what I'm running:

That'd be awesome if you could, I'll likely not be able to dig deep into this until the weekend otherwise.

I'm attaching a zip file with a test setup (just run . sourceme.sh), or if you're not feeling adventurous enough to download a zip file, here are the contents:

sourceme.sh:

# Build static archive:
gcc -fPIC -c bvers.f -o libbvers.a

### Python 3.6/distutils backend (works for me):
python3.6 -m numpy.f2py --verbose -c _bufrlib.pyf -m _bufrlib -L$PWD -lbvers --build-dir builddir-distutils
python3.6 -c "import ncepbufr" |& tee python36.output

### Python 3.12/Meson backend (does not work for me):
. /opt/spack_nov23/share/spack/setup-env.sh
spack env activate python-312-gcc-11
spack load python meson

rm _bufrlib.cpython-312*.so
LDFLAGS=$PWD/libbvers.a python3.12 -m numpy.f2py --verbose -c _bufrlib.pyf -m _bufrlib --backend meson --build-dir builddir-mesonA
python3.12 -c "import ncepbufr" |& tee python312_A.output
rm _bufrlib.cpython-312*.so
LDFLAGS="-L$PWD -lbvers" python3.12 -m numpy.f2py --verbose -c _bufrlib.pyf -m _bufrlib --backend meson --build-dir builddir-mesonB
python3.12 -c "import ncepbufr" |& tee python312_B.output
rm _bufrlib.cpython-312*.so
CFLAGS="-L$PWD -lbvers" python3.12 -m numpy.f2py --verbose -c _bufrlib.pyf -m _bufrlib --backend meson --build-dir builddir-mesonC
python3.12 -c "import ncepbufr" |& tee python312_C.output

bvers.f:

        SUBROUTINE BVERS (CVERSTR)
        CHARACTER*(*)   CVERSTR
        CVERSTR = 'myver'
        RETURN
        END

_bufrlib.pyf:

python module _bufrlib
    interface
        subroutine bvers(cverstr) ! in bvers.f
            character*12,intent(out) :: cverstr
        end subroutine bvers
    end interface 
end python module _bufrlib

ncepbufr/__init__.py:

import _bufrlib
__bufrlib_version__ = _bufrlib.bvers().rstrip()
print("successful load")

f2pytestcase_28nov23.zip

I can't seem to reproduce this locally anymore:

❯ tree .
.
├── _bufrlib.pyf
├── bvers.f
├── libbvers.a
├── ncepbufr
└── sourceme.sh

2 directories, 4 files

# Compile
❯ gcc -fPIC -c bvers.f -o libbvers.a
# Version check (main)
❯ f2py -v
2.0.0.dev0+git20231209.35c4319

# Distutils
❯ f2py --verbose -c _bufrlib.pyf -m _bufrlib -L$PWD -lbvers --build-dir builddir-distutils
❯ python -c "import ncepbufr" |& tee distutils.output
successful load

# Cleanup
❯ rm -rf *.output *.so builddir*

# Meson
❯ f2py --verbose -c _bufrlib.pyf -m _bufrlib -L$PWD -lbvers --backend meson --build-dir builddir-meson
❯ python -c "import ncepbufr" |& tee meson.output
successful load

The meson.build should include:

bvers = declare_dependency(link_args : ['-lbvers'])
lib_dir_0 = declare_dependency(link_args : ['-L/home/rgoswami/Git/Github/Quansight/numscipy_playground/numpy_bugs/gh-25266'])

py.extension_module('_bufrlib',
                     [
'_bufrlibmodule.c',
                     '_bufrlib-f2pywrappers.f',
                     fortranobject_c
                     ],
                     include_directories: [inc_np],
                     dependencies : [
                     py_dep,
                     quadmath_dep,

bvers,
lib_dir_0,
                     ],
                     install : true)

Which was added last week in #25297. Please reopen if it persists @AlexanderRichert-NOAA.

Thanks @HaoZeke. I'm unable to test at the moment, but #25297 certainly looks directly relevant. Do you know when that will be in a release?