Numpy: [BUG] f2py kann das Erweiterungsmodul nicht kompilieren, wenn zuerst C-Quellen generiert werden

Erstellt am 22. Nov. 2019  ·  7Kommentare  ·  Quelle: numpy/numpy

Wenn Sie gemäß dem Dokument / Benutzerhandbuch von f2py eine .c -Datei mit dem Erweiterungsmodul generieren möchten, müssen Sie dies tun

$ f2py -m fib1 fib1.f

um eine fib1module.c Datei zu generieren. Das funktioniert. Der nächste Schritt zum Erstellen des Erweiterungsmoduls, das gemäß den Dokumenten in Python importiert werden kann, ist jedoch

$ f2py -c fib1module.c

Dies schlägt jedoch bei folgenden Meldungen fehl:

$ f2py -c fib1module.c --verbose
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options
running build_src
build_src
building extension "untitled" sources
build_src: building npy-pkg config files
running build_ext
new_compiler returns <class 'distutils.unixccompiler.UnixCCompiler'>
customize UnixCCompiler
customize UnixCCompiler using build_ext
********************************************************************************
<class 'distutils.unixccompiler.UnixCCompiler'>
preprocessor  = ['gcc', '-pthread', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-Wl,--sysroot=/', '-E']
compiler      = ['gcc', '-pthread', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-Wl,--sysroot=/', '-Wsign-compare', '-DNDEBUG', '-g', '-fwrapv', '-O3', '-Wall', '-Wstrict-prototypes', '-std=c99']
compiler_so   = ['gcc', '-pthread', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-Wl,--sysroot=/', '-Wsign-compare', '-DNDEBUG', '-g', '-fwrapv', '-O3', '-Wall', '-Wstrict-prototypes', '-fPIC', '-std=c99']
compiler_cxx  = ['g++', '-pthread', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-Wl,--sysroot=/']
linker_so     = ['gcc', '-pthread', '-shared', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-L/opt/miniconda/envs/numpy-dev/lib', '-Wl,-rpath=/opt/miniconda/envs/numpy-dev/lib', '-Wl,--no-as-needed', '-Wl,--sysroot=/']
linker_exe    = ['gcc', '-pthread', '-B', '/opt/miniconda/envs/numpy-dev/compiler_compat', '-Wl,--sysroot=/']
archiver      = ['ar', 'rc']
ranlib        = None
libraries     = []
library_dirs  = []
include_dirs  = ['/opt/miniconda/envs/numpy-dev/include/python3.6m']
********************************************************************************
building 'untitled' extension
compiling C sources
C compiler: gcc -pthread -B /opt/miniconda/envs/numpy-dev/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -std=c99

compile options: '-I/home/melissa/projects/numpy/numpy/core/include -I/opt/miniconda/envs/numpy-dev/include/python3.6m -c'
gcc: fib1module.c
fib1module.c:16:10: fatal error: fortranobject.h: Arquivo ou diretório inexistente
   16 | #include "fortranobject.h"
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
error: Command "gcc -pthread -B /opt/miniconda/envs/numpy-dev/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -std=c99 -I/home/melissa/projects/numpy/numpy/core/include -I/opt/miniconda/envs/numpy-dev/include/python3.6m -c fib1module.c -o /tmp/tmpyjgu4iq5/fib1module.o -MMD -MF /tmp/tmpyjgu4iq5/fib1module.o.d" failed with exit status 1

Tun

$ f2py -c fib1module.c -I/home/melissa/projects/numpy/numpy/f2py/src -m fib1module

scheint zu funktionieren (dies ist der Speicherort meiner fortranobject.h -Datei), aber dann kann das Modul nicht importiert werden:

>>> import fib1module
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /home/melissa/projects/numpy/doc/source/f2py/fib1module.cpython-36m-x86_64-linux-gnu.so: undefined symbol: PyFortran_Type

TL; DR: Ist dies ein Fehler oder etwas, das wir nicht tun sollten (generieren Sie .c Quellen und erstellen Sie dann das Erweiterungsmodul in einem separaten Schritt)?

>>> import sys, numpy; print(numpy.__version__, sys.version)
1.18.0.dev0+8d217b0 3.6.7 | packaged by conda-forge | (default, Jul  2 2019, 02:18:42) 
[GCC 7.3.0]
00 - Bug numpy.f2py

Hilfreichster Kommentar

Ich bin nicht sicher, welche Dokumente dies sagen, aber Folgendes ist falsch:

$ f2py -c fib1module.c

f2py -c ... muss entweder auf vorhandene .pyf -Dateien (plus die Quell- / Objekt- / Bibliotheksdateien) angewendet werden oder es muss die Option -m <modulename> (plus die Quellen- / Objekt- / Bibliotheksdateien) angegeben werden. . f2py -c ist nicht dazu gedacht, die generierten C / API-Erweiterungsmodule direkt zu kompilieren (obwohl dies wahrscheinlich mit den richtigen Include-Verzeichnisflags und den Eingaben der Quell- / Objektdatei möglich ist).

Verwenden Sie eine der folgenden Optionen:

f2py -c -m fib1 fib1.f

oder

f2py -m fib1 fib1.f -h fib1.pyf
f2py -c fib1.pyf fib1.f

Diese Beispiele sind insofern minimal, als ein Fehler erwartet wird, wenn in den obigen f2py-Befehlszeilen etwas übersprungen wird.

Alle 7 Kommentare

Danke für den Bericht @melissawm. Wir sprechen über diese Seite richtig: https://numpy.org/devdocs/f2py/getting-started.html?

Ich kann bestätigen, was Sie sehen:

$ f2py -m fib1 fib1.f
$ f2py -c fib1module.c
...
fib1module.c:16:10: fatal error: 'fortranobject.h' file not found
#include "fortranobject.h"

Die Dokumentseite führt jedoch stattdessen $ f2py -c -m fib1 fib1.f (generieren Sie Code und kompilieren Sie ihn auf einmal), und das funktioniert für mich wie erwartet. Ich bin mir nicht sicher, ob die Trennung von -m und -c jemals unterstützt wurde. Es sollte möglich sein, -c Laufen zu bringen, indem automatisch der richtige Include-Pfad hinzugefügt wird - wahrscheinlich nicht schwer, aber nicht sicher, ob er benötigt wird.

@pearu irgendwelche Gedanken?

Ich bin nicht sicher, welche Dokumente dies sagen, aber Folgendes ist falsch:

$ f2py -c fib1module.c

f2py -c ... muss entweder auf vorhandene .pyf -Dateien (plus die Quell- / Objekt- / Bibliotheksdateien) angewendet werden oder es muss die Option -m <modulename> (plus die Quellen- / Objekt- / Bibliotheksdateien) angegeben werden. . f2py -c ist nicht dazu gedacht, die generierten C / API-Erweiterungsmodule direkt zu kompilieren (obwohl dies wahrscheinlich mit den richtigen Include-Verzeichnisflags und den Eingaben der Quell- / Objektdatei möglich ist).

Verwenden Sie eine der folgenden Optionen:

f2py -c -m fib1 fib1.f

oder

f2py -m fib1 fib1.f -h fib1.pyf
f2py -c fib1.pyf fib1.f

Diese Beispiele sind insofern minimal, als ein Fehler erwartet wird, wenn in den obigen f2py-Befehlszeilen etwas übersprungen wird.

Eigentlich spreche ich über diese Seite: https://numpy.org/devdocs/f2py/usage.html

Dort haben wir in Punkt 2 und 3 Folgendes: Punkt 2 besteht darin, f2py ohne die Optionen -m oder -c auszuführen, was anscheinend nicht funktioniert. Punkt 3 sagt

Verwenden Sie zum Erstellen eines Erweiterungsmoduls

f2py -c <options> <fortran files>       \
  [[ only: <fortran functions>  : ]     \
   [ skip: <fortran functions>  : ]]... \
  [ <fortran/c source files> ] [ <.o, .a, .so files> ]

Wenn <fortran files> eine Signaturdatei enthält, wird eine Quelle für ein Erweiterungsmodul erstellt.
Alle Fortran- und C-Quellen werden kompiliert, und schließlich werden alle Objekt- und Bibliotheksdateien mit dem verknüpft
Erweiterungsmodul <modulename>.so das im aktuellen Verzeichnis gespeichert wird.

Wenn <fortran files> keine Signaturdatei enthält, wird ein Erweiterungsmodul von erstellt
Scannen aller Fortran-Quellcodes nach Routinesignaturen.

Nach dem, was Sie gesagt haben, sollten wir die .c -Quellen nicht direkt verwenden, oder? Wenn wir eine .c -Datei generieren, ist sie später unbrauchbar?

Danke für die Eingabe!

Eigentlich spreche ich über diese Seite: https://numpy.org/devdocs/f2py/usage.html

Diese Seite beschreibt die Befehlszeilenoptionen f2py und die verschiedenen Modi. Es wird vorausgesetzt, dass man versteht, wie Python-Erweiterungsmodule erstellt werden können, siehe zum Beispiel https://docs.python.org/3.8/extending/index.html

Während f2py zum Erstellen von Erweiterungsmodulen verwendet werden kann, die auch C-Funktionen (in .c -Dateien enthalten) einschließen, ist die Aussage "Wir sollten die .c-Quellen nicht direkt verwenden" ungenau.

Man sollte die .c f2py generierten .c -Dateien unterscheiden, die Benutzerimplementierungen von C-Funktionen enthalten. Die .c f2py generierte

Ich füge die Erklärung von

Fühlen Sie sich frei, das Problem zu schließen (oder sollte ich es erst tun, nachdem diese PR akzeptiert wurde?)

Ich schlage vor, zu schließen, wenn die PR, die dieses Problem angeht, akzeptiert wird.

Ich schlage vor, zu schließen, wenn die PR, die dieses Problem angeht, akzeptiert wird.

+1

@melissawm Sie können auch closes gh-14960 zu einer Ihrer Commit-Nachrichten hinzufügen. Dann wird das Problem automatisch geschlossen, wenn der PR zusammengeführt wird.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen