Numpy: [バグ] Cソースが最初に生成された場合、f2pyは拡張モジュールをコンパイルできません

作成日 2019年11月22日  ·  7コメント  ·  ソース: numpy/numpy

f2pyのドキュメント/ユーザーガイドに従って、拡張モジュールを使用して.cファイルを生成する場合は、次のことを行う必要があります。

$ f2py -m fib1 fib1.f

fib1module.cファイルを生成します。 これは機能します。 ただし、ドキュメントによると、Pythonでインポートできる拡張モジュールを構築するための次のステップは次のとおりです。

$ f2py -c fib1module.c

ただし、これは次のメッセージで失敗します。

$ 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

やってる

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

動作しているようですが(これは私のfortranobject.hファイルの場所です)、モジュールはインポートできません。

>>> 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:これはバグですか、それとも私たちが行うべきではないことですか( .cソースを生成してから、別のステップで拡張モジュールをビルドします)?

>>> 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

最も参考になるコメント

どのドキュメントがこれを言っているのかわかりませんが、以下は間違っています:

$ f2py -c fib1module.c

f2py -c ...は、既存の.pyfファイル(およびソース/オブジェクト/ライブラリファイル)に適用するか、 -m <modulename>オプション(およびソース/オブジェクト/ライブラリファイル)を指定する必要があります。 。 f2py -cは、生成されたC / API拡張モジュールを直接コンパイルすることを意図したものではありません(ただし、適切なインクルードディレクトリフラグとソース/オブジェクトファイル入力を使用してコンパイルできる可能性があります)。

次のいずれかのオプションを使用します。

f2py -c -m fib1 fib1.f

または

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

これらの例は、上記のf2pyコマンドラインで何かがスキップされた場合に失敗が予想されるという意味で最小限です。

全てのコメント7件

@melissawmのレポートをありがとう。 私たちはこのページについて正しく話している: https

私はあなたが見ているものを確認することができます:

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

ただし、ドキュメントページは代わりに$ f2py -c -m fib1 fib1.fを実行し(コードを生成して一度にコンパイルします)、それは私にとって期待どおりに機能します。 -m-c分離がサポートされたことがあるかどうかはわかりません。 正しいインクルードパスを自動的に追加することで、 -cのみを機能させることができるはずです。おそらく難しいことではありませんが、必要かどうかはわかりません。

@pearu何か考えはありますか?

どのドキュメントがこれを言っているのかわかりませんが、以下は間違っています:

$ f2py -c fib1module.c

f2py -c ...は、既存の.pyfファイル(およびソース/オブジェクト/ライブラリファイル)に適用するか、 -m <modulename>オプション(およびソース/オブジェクト/ライブラリファイル)を指定する必要があります。 。 f2py -cは、生成されたC / API拡張モジュールを直接コンパイルすることを意図したものではありません(ただし、適切なインクルードディレクトリフラグとソース/オブジェクトファイル入力を使用してコンパイルできる可能性があります)。

次のいずれかのオプションを使用します。

f2py -c -m fib1 fib1.f

または

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

これらの例は、上記のf2pyコマンドラインで何かがスキップされた場合に失敗が予想されるという意味で最小限です。

実際、私はこのページについて話している: https

項目2と3には、次のものがあります。項目2は、 -mまたは-cオプションなしでf2pyを実行することですが、これは明らかに機能しません。 項目3は言う

拡張モジュールを構築するには、

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

<fortran files>に署名ファイルが含まれている場合、拡張モジュールのソースが作成されます。
すべてのFortranおよびCソースがコンパイルされ、最後にすべてのオブジェクトおよびライブラリファイルがにリンクされます。
現在のディレクトリに保存されている拡張モジュール<modulename>.so

<fortran files>署名ファイルが含まれていない場合、拡張モジュールはによって構築されます。
すべてのFortranソースコードをスキャンしてルーチンの署名を探します。

あなたが言ったことから、私たちは.cソースを直接使用することになっていないことを理解していますよね? .cファイルを生成した場合、後で使用できなくなりますか?

入力ありがとうございます!

実際、私はこのページについて話している: https

このページでは、 f2pyコマンドラインオプションとさまざまなモードについて説明します。 Python拡張モジュールの構築方法を理解していることを前提としていますたとえばください。

f2pyは、C関数( .cファイルに含まれる)もラップする拡張モジュールの作成に使用できるため、「。cソースを直接使用することは想定されていません」という記述は不正確です。

一つは区別する必要があります.c f2pyが生成したファイルを.c C関数のユーザーの実装を含むファイル。 f2pyが生成する.cファイルは、拡張モジュールの構築方法を完全に制御する必要がある場合、またはf2pyをデバッグする場合にのみ役立ちます。 それ以外の場合はすべて、ビルドプロセスで自動的に生成されるため、拡張モジュールを生成する必要はありません。

上記の@pearuの説明を

問題を自由にクローズしてください(または、PRが承認された後にのみクローズする必要がありますか?)

この問題に取り組むPRが受け入れられたら閉じることをお勧めします。

この問題に取り組むPRが受け入れられたら閉じることをお勧めします。

+1

@melissawmコミットメッセージの1つにcloses gh-14960を追加することもできます。そうすると、PRがマージされるときに問題が自動的にクローズされます。

このページは役に立ちましたか?
0 / 5 - 0 評価