10000 BUG: f2py undefined symbol for the new meson backend · Issue #28191 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

BUG: f2py undefined symbol for the new meson backend #28191

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1234zou opened this issue Jan 20, 2025 · 5 comments
Open

BUG: f2py undefined symbol for the new meson backend #28191

1234zou opened this issue Jan 20, 2025 · 5 comments
Labels
00 - Bug component: numpy.f2py

Comments

@1234zou
Copy link
1234zou commented Jan 20, 2025 •
edited
Loading

Describe the issue:

This is a continued problem of a previous numpy f2py issue. The error information is different and I think it deserves opening a new issue. After adding -I$(pwd) to f2py, there is no compilation error, but there is an importing error undefined symbol. The following test is performed using Python 3.12.8 and gcc 8.5.0.

Thanks for any kind help and suggestion!

Best,
Jingxiang

Reproduce the code example:

A simple example is shown using two Fortran files and one Python script:
a.f90

module para
 implicit none
 integer :: n
end module para

b.f90

subroutine prt_n
 use para, only: n
 implicit none
 n = 5
 write(6,'(A,I2)') 'n=', n
end subroutine prt_n

Compiling commands are

gfortran a.f90 -c
f2py -c a.o b.f90 -m test -I$(pwd)

The file test.cpython-312-x86_64-linux-gnu.so is generated.

Error message:

Start python and it can be found

>>>from test import prt_n
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /public/home/jxzou/wfu/pbc_pm_test/test.cpython-312-x86_64-linux-gnu.so: undefined symbol: __para_MOD_n

which means that the integer variable n seems not be used during compiling.

Python and NumPy Versions:

Python 3.12.8, numpy 2.2.1

Runtime Environment:

[{'numpy_version': '2.2.1',
  'python': '3.12.8 | packaged by Anaconda, Inc. | (main, Dec 11 2024, '
            '16:31:09) [GCC 11.2.0]',
  'uname': uname_result(system='Linux', node='mu012', release='4.18.0-372.64.1.kos5.x86_64', version='#1 SMP Tue Aug 8 20:23:39 EDT 2023', machine='x86_64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3',
                                'SSE41',
                                'POPCNT',
                                'SSE42',
                                'AVX',
                                'F16C',
                                'FMA3',
                                'AVX2',
                                'AVX512F',
                                'AVX512CD',
                                'AVX512_SKX',
                                'AVX512_CLX',
                                'AVX512_CNL',
                                'AVX512_ICL'],
                      'not_found': ['AVX512_KNL', 'AVX512_KNM']}},
 {'filepath': '/public/home/jxzou/software/anaconda3/envs/mokit-py312/lib/libmkl_rt.so.2',
  'internal_api': 'mkl',
  'num_threads': 64,
  'prefix': 'libmkl_rt',
  'threading_layer': 'intel',
  'user_api': 'blas',
  'version': '2023.1-Product'},
 {'filepath': '/public/home/jxzou/software/anaconda3/envs/mokit-py312/lib/libiomp5.so',
  'internal_api': 'openmp',
  'num_threads': 64,
  'prefix': 'libiomp',
  'user_api': 'openmp',
  'version': None}]

Context for the issue:

We are developers of the open source package MOKIT. By using f2py, we offer lots of convenient and efficient Python APIs to users in the computational chemistry field. We are grateful for your numpy f2py functionalities. And we are still looking for a solution to move to new meson backend. Thank you.
@HaoZeke
Copy link
Member
HaoZeke commented Jan 20, 2025

Unfortunately this is a conceptual issue and cannot be resolved by f2py. Recall that what f2py does is generate bindings to fortran code. In this instance, from the .mod file, there is no way for f2py to generate bindings. The solution is to pass both files to f2py.

python -mnumpy.f2py -c a.f90 b.f90 -m test

Note the difference in the generated files, the error arises because the mod file is not parsed by f2py so the following bindings are not generated:

❯ diff blah_mod/testmodule.c blah/testmodule.c 
5c5
<  * Generation date: Mon Jan 20 11:07:03 2025
---
>  * Generation date: Mon Jan 20 11:06:26 2025
180a181,195
> 
> static FortranDataDef f2py_para_def[] = {
>   {"n",0,{{-1}},NPY_INT, 1},
>   {NULL}
> };
> 
> static void f2py_setup_para(char *n) {
>   int i_f2py=0;
>   f2py_para_def[i_f2py++].data = n;
> }
> extern void F_FUNC(f2pyinitpara,F2PYINITPARA)(void (*)(char*));
> static void f2py_init_para(void) {
>   F_FUNC(f2pyinitpara,F2PYINITPARA)(f2py_setup_para);
> }
> 
230c245
< ".");
---
> "Fortran 90/95 modules:\n""  para --- n"".");
249a265
>   PyDict_SetItemString(d, "para", PyFortranObject_New(f2py_para_def,f2py_init_para));

FWIW this can never have worked in older versions of f2py as well (tested with 1.21.6 and Python 3.7 as well) so it is not really related to the meson backend.

@HaoZeke HaoZeke closed this as completed Jan 20, 2025
@jeanwsr
Copy link
jeanwsr commented Jan 20, 2025 •
edited
Loading

I'm pretty sure this example (f2py -c a.o b.f90 -m test) works with previous backend of f2py. Tested with python 3.11, numpy 2.2.2 from conda-forge.

@1234zou
Copy link
Author
1234zou commented Jan 20, 2025

Thanks to everyone's helpful discussion. I also tested three versions and f2py -c a.o b.f90 -m test does work with previous backend of f2py

python 3.7.16, numpy 1.21.5
python 3.9.21, numpy 2.0.2
python 3.10, numpy 2.2.1

@HaoZeke
Copy link
Member
HaoZeke commented Jan 20, 2025 •
edited
Loading

Ah my bad, reopening. In my haste I thought it was a compilation with only the .mod files. Will look into this soon.

@HaoZeke HaoZeke reopened this Jan 20, 2025
@xianrui5891
Copy link

Dear all,
This problem exhausts me too. I reviewed the build dir and I founded nijia didn't link the .ofile we had prepared.

And by my test, i found that it also can be happened on .a .sofiles.

So could anyone tell me it have any process now? This problem prevent us from switching to meson backend.

Best wishes,
XianruiZhu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy.f2py
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@HaoZeke @1234zou @jeanwsr @xianrui5891
0