I'm creating a shared Python extension for my library and I'm using distutils to build it.
These are the relevant sections of my setup.py:
import distuitls.core as dc
from os.path import join as path_join
module = dc.Extension(module_name,
sources = [path_join(meson_src_root, "py3_bindings", "module.c")],
include_dirs = [path_join(meson_src_root, "include")],
libraries = ["bbmputil"],
runtime_library_dirs = [meson_build_root])
dc.setup(name = module_name,
version = module_version,
description = "Python3 bindings for the bbmp_utils library",
ext_modules = [module])
Running $ setup.py build results in the shared extension module being built successfully, but it isn't getting linked against the "bbmputil" library.
$ ldd build/lib.linux-x86_64-3.8/bbmp_utils.cpython-38-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffc85ce1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f49f0d70000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f49f0f74000)
libbbmputil.so is nowhere to be found, despite being specified in the libraries kwarg of Extension().
It does exist in the location specified in the runtime_library_dirs kwarg.
This leads to the python interpreter raising an ImportError exception when a symbol from the non-linked library is referenced in the extension:
$ env PYTHONPATH="sharedextension_build_path" python3
>>> import bbmp_utils
ImportError: /home/bogdan/dev/bbmp_utils/build_dbg/build/lib.linux-x86_64-3.8/bbmp_utils.cpython-38-x86_64-linux-gnu.so: undefined symbol: bbmp_vertflip
where bbmp_vertflip is a symbol defined in the library that doesn't seem to be linked for some reason.
The two C compiler invocations look as follows:
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fPIC -I/home/bogdan/dev/bbmp_utils/include -I/usr/include/python3.8 -c /home/bogdan/dev/bbmp_utils/py3_bindings/module.c -o build/temp.linux-x86_64-3.8/home/bogdan/dev/bbmp_utils/py3_bindings/module.o
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now build/temp.linux-x86_64-3.8/home/bogdan/dev/bbmp_utils/py3_bindings/module.o -L/usr/lib -Wl,--enable-new-dtags,-R/home/bogdan/dev/bbmp_utils/build_dbg -lbbmputil -o build/lib.linux-x86_64-3.8/bbmp_utils.cpython-38-x86_64-linux-gnu.so
In the 2nd invocation both -lbbmputil as well as -R are passed properly when building the shared extension so I'm out of ideas.
Minimal example producing the same behavior
Attempting to build a module that utilizes functions and other symbols from the math shared library:
#!/usr/bin/env python3
import distutils.core as dc
module = dc.Extension('example',
sources = ['example.c'],
libraries = ['m'])
dc.setup(name = 'example',
version = '0.1',
ext_modules = [module])
$ ./setup.py build
$ ldd .../.../example.cpython-38-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffd0b9e5000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fab528e8000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007fab52aec000)
Again, libm.so dependency is nowhere to be found.
Environment:
python3 3.8.1
linux 5.4.6
gcc 9.2.0
ld 2.33.1
ldd 2.3.0
UPDATE : The problem in this case is the linker optimization option
--as-needed that is enabled by default, see
Missing a library in ldd after using gcc -l
Adding --no-as-needed fixes this error
For debugging linker errors you can use LD_DEBUG=files,libs /usr/local/ABC/bin/ABC where ABC is the executable that throws linker errors at runtime, cf http://www.bnikolic.co.uk/blog/linux-ld-debug.html and libm.so.6: cannot open shared object file: No such file or directory On linux you locate a .so with i.e. locate libm (i think you know this)
As the linking is dynamically it is an option to specify the path where your .so files can be found using the library_dirs option of disutils.core that is the -L or equivalently LD_LIBRARY_PATH gcc linker option and for reasons of debugging and testing i would use the absolute path (https://docs.python.org/2/distutils/apiref.html)
In your python minimal example the code is then :
#!/usr/bin/env python3
import distutils.core as dc
module = dc.Extension('example',
sources = ['example.c'],
library_dirs = ['/usr/lib/x86_64-linux-gnu/libm.so'],
libraries = ['m'])
dc.setup(name = 'example',
version = '0.1',
ext_modules = [module])
You use the -R linker flag to specify the rpath in your gcc invokation, cf Shared library dependencies with distutils and What does the gcc -R parameter do? . In https://www.mpcdf.mpg.de/services/computing/software/libraries/static-and-dynamic-linking-on-linux-systems is a description of the linking process. It is said that LD_LIBRARY_PATH or equivalently the -L gcc linker option overrides the rpath and that it should be avoided, however you should give it a try anyway ...
Another possiblity for this behavior could be permission problems, i.e. when you execute example does it have the permission to access libm cf https://unix.stackexchange.com/questions/303292/permission-denied-on-some-shared-libraries
Related
This question is related to a couple of questions in SO like this one and this other one. Unfortunately the solution there is not working for me so far. I have a module.pxc file which I am compiling by a setup.py file, such as the following one:
# setup.py
module_extension = Extension(
name="iolif",
sources=["/home/maurizio/Ongoing.Projects/c_libraries/dcomplex_libc.c",
"/home/maurizio/Ongoing.Projects/c_libraries/special_functions_libc.c",
"/home/maurizio/Ongoing.Projects/c_libraries/models/freq_cv_libc.c",
"module.pyx"],
libraries=['gsl', 'gslcblas', 'm'],
# library_dirs=["lib"],
include_dirs=["/home/maurizio/Ongoing.Projects/pycustommodules",
"/home/maurizio/Ongoing.Projects/c_libraries",
"/home/maurizio/Ongoing.Projects/c_libraries/models"]
)
setup(
name="iolif",
ext_modules=cythonize([module_extension])
)
From command line, in the same directory of module.pxc, when writing python setup.py build_ext --inplace compilation works fine, and the iolif.so library is produced. The issue is that I can only import this library if I use Python2.7, whereas if I attempt to import it in Python3.x I get the known ImportError: dynamic module does not define module export function (PyInit_iolif).
Googling around, and as pointed out in the two questions linked above, it seems that this is due to the fact that cython is looking at Python2.7 rather than Python3.x (which is the one I work with instead). Accordingly, I attempted asking cythonize in my setup.py to use Python3.x by:
...
setup(
name="iolif",
ext_modules=cythonize([module_extension],
compiler_directives={'language_level': "3"})
)
but it still does not work. The last compilation message indeed produces:
gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -
specs=/usr/lib/rpm/redhat/redhat-hardened-ld build/temp.linux-x86_64-2.7/pylif_io.o
build/temp.linux-x86_64-2.7/home/maurizio/Ongoing.Projects/c_libraries/dcomplex_libc.o
build/temp.linux-x86_64-2.7/home/maurizio/Ongoing.Projects/c_libraries/special_functions_libc.o build/temp.linux-x86_64-2.7/home/maurizio/Ongoing.Projects/c_libraries/models/freq_cv_libc.o -L/usr/lib64
-lgsl -lgslcblas -lm -lpython2.7 -o /home/maurizio/Ongoing.Projects/DePitta.PNAS/Software/LIF.Analysis/iolif.so
where you can see that it is still linking with the -lpython2.7 library (whereas it should use for example -lpython3.7m). How do I solve it? What am I missing?
Easy solution. My python command was still associated with python2.7 (I recently moved to Python3.x). Sorry about it. Hence:
python3 setup.py build_ext --inplace
will make the trick. Indeed compilation now reads:
gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g build/temp.linux-x86_64-3.7/pylif_io.o build/temp.linux-x86_64-3.7/home/maurizio/Ongoing.Projects/c_libraries/dcomplex_libc.o build/temp.linux-x86_64-3.7/home/maurizio/Ongoing.Projects/c_libraries/special_functions_libc.o build/temp.linux-x86_64-3.7/home/maurizio/Ongoing.Projects/c_libraries/models/freq_cv_libc.o -L/usr/lib64 -lgsl -lgslcblas -lm -lpython3.7m -o /home/maurizio/Ongoing.Projects/DePitta.PNAS/Software/LIF.Analysis/iolif.cpython-37m-x86_64-linux-gnu.so
as required.
I am adding python 2.7.13 as an altinstall by installing the source code to my RHEL4 box with
wget --no-check-certificate https://www.python.org/ftp/python/2.7.13/Python-2.7.13.tar.xz
tar -xvzf Python2.7.13.tar.xz
cd Python2.7.13
./configure --with-ensurepip=install
make
make test
make altinstall
so that I do not overwrite the default python that is required for other use. Python 2.7.13 would successfully install but was missing several essential modules for the project I am working on.
Originally the _ssl and _haslib modules would error in this section.
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _tkinter
bsddb185 dbm dl
gdbm imageop sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
I installed openssl and ensured that they were in the default location that python was looking for them, so now I have the necessary bits but then it ends with this message instead
Failed to build these modules:
_hashlib _ssl
Below is the entire output of the python2.7 setup.py build from the unzipped python package. I have been scouring google and anywhere I can find but I have been unsuccessful in anything so far
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_ssl' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/ssl/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/include/python2.7 -c /Python/Modules/_ssl.c -o build/temp.linux-x86_64-2.7/Python/Modules/_ssl.o
/Python/Modules/_ssl.c:57: warning: ignoring #pragma GCC diagnostic
/Python/Modules/_ssl.c: In function ‘_setup_ssl_threads’:
/Python/Modules/_ssl.c:4012: warning: comparison is always false due to limited range of data type
gcc -pthread -shared build/temp.linux-x86_64-2.7/Python/Modules/_ssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-2.7/_ssl.so
/usr/bin/ld: /usr/local/ssl/lib/libssl.a(s3_meth.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/ssl/lib/libssl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
building '_hashlib' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/ssl/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/include/python2.7 -c /Python/Modules/_hashopenssl.c -o build/temp.linux-x86_64-2.7/Python/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-x86_64-2.7/Python/Modules/_hashopenssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-2.7/_hashlib.so
/usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(o_names.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/ssl/lib/libcrypto.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _tkinter
bsddb185 dbm dl
gdbm imageop sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
_hashlib _ssl
running build_scripts
When I attempt to use pip that is installed with my python 2.7.13 I get an SSL error so I have been installing all my packages and other modules from the source like cx_Oracle and CherryPy.
pip2.7 install cffi
pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Collecting cffi
Could not fetch URL https://pypi.python.org/simple/cffi/: There was a problem confirming the ssl certificate: Can't connect to HTTPS URL because the SSL module is not available. - skipping
Could not find a version that satisfies the requirement cffi (from versions: )
No matching distribution found for cffi
I also tried to add the ssl module manually with
wget --no-check-certificate https://pypi.python.org/packages/83/21/f469c9923235f8c36d5fd5334ed11e2681abad7e0032c5aba964dcaf9bbb/ssl-1.16.tar.gz#md5=fb12d335d56f3c8c7c1fefc1c06c4bfb
tar -xvzf ssl-1.16.tar.gz
cd ssl-1.16
python2.7 setup.py build
But I get an error that it should not be used with python past 2.6
Traceback (most recent call last):
File "setup.py", line 12, in <module>
+ "or earlier.")
ValueError: This extension should not be used with Python 2.6 or later (already built in), and has not been tested with Python 2.3.4 or earlier.
EDIT
I was looking around for solutions and after combing over the outputs of the setup.py build and found someone with a similar-ish problem that seems to be related to openssl here
so I rebuilt my openssl with
./config enable-shared
make
make test
make install
and now I get a slightly different error about the ssl module, am I just screwing up my environment more and more?
python2.7 setup.py build
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_ssl' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/ssl/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/include/python2.7 -c /Python/Modules/_ssl.c -o build/temp.linux-x86_64-2.7/Python/Modules/_ssl.o
/Python/Modules/_ssl.c:57: warning: ignoring #pragma GCC diagnostic
/Python/Modules/_ssl.c: In function ‘_setup_ssl_threads’:
/Python/Modules/_ssl.c:4012: warning: comparison is always false due to limited range of data type
gcc -pthread -shared build/temp.linux-x86_64-2.7/Python/Modules/_ssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-2.7/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: libssl.so.1.0.0: cannot open shared object file: No such file or directory
building '_hashlib' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/ssl/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/include/python2.7 -c /Python/Modules/_hashopenssl.c -o build/temp.linux-x86_64-2.7/Python/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-x86_64-2.7/Python/Modules/_hashopenssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-2.7/_hashlib.so
*** WARNING: renaming "_hashlib" since importing it failed: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _tkinter
bsddb185 dbm dl
gdbm imageop sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
_hashlib _ssl
running build_scripts
The new warning message in the output *** WARNING: renaming "_ssl" since importing it failed: libssl.so.1.0.0: cannot open shared object file: No such file or directory indicates that the file does not exist but I see it in /usr/local/ssl/lib/ as libssl.so.1.0.0 and can find it with a search
find / -name libssl.so.1.0.0
/usr/local/ssl/lib/libssl.so.1.0.0
/tmp/openssl-1.0.2l/libssl.so.1.0.0
Well, I don't know whether to feel stupid and this is just a common thing I completely overlooked doing since I am fairly new to linux CLI. But, I was able to resolve my build error for the _hashlib and _ssl modules with a couple simple steps in https://stackoverflow.com/a/28460293/8222554 amo's response.
I first attempted the ldconfig but that did not resolve my issue so I simply looked at what was in my LD_LIBRARY_PATH with
echo $LD_LIBRARY_PATH
and then got back these locations which did not include where the libssl.so.1.0.0 file was located
/usr/lib/oracle/11.2/client64/lib:/usr/lib/oracle/11.2/client/lib
Then I followed the steps I had done previously when installing the Oracle instant client and cx_Oracle module which were easily laid out on on this blog post: https://ubuntugeeknerd.blogspot.com/2013/08/how-to-install-oxoracle-in-rhel-64-bit.html
Those steps I used for the ssl module were as follow
export LD_LIBRARY_PATH=/usr/local/ssl/lib/:$LD_LIBRARY_PATH >> ~/.bashrc
echo $LD_LIBRARY_PATH
/usr/local/ssl/lib/:/usr/lib/oracle/11.2/client64/lib:/usr/lib/oracle/11.2/client/lib
After this I did python2.7 setup.py clean followed by python2.7 setup.py build and last python2.7 setup.py install. The output didn't return any failed to build besides the ones which I did not have the necessary bits for (and was not looking to build anyways).
I can verify the ssl module is there now when opening up python and importing the module successfully
Python 2.7.13 (default, Jun 26 2017, 15:21:33)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>>
Hopefully this will be handy to someone who is running into a similar issue
I'm trying to compile a simple python/C example following this tutorial:
http://www.swig.org/tutorial.html
I'm on MacOS using Anaconda python.
however, when I run
gcc -c example.c example_wrap.c -I/Users/myuser/anaconda/include/
I get:
example_wrap.c:130:11: fatal error: 'Python.h' file not found
# include <Python.h>
^
It seems that this problem is reported in a number of questions:
Missing Python.h while trying to compile a C extension module
Missing Python.h and impossible to find
Python.h: No such file or directory
but none seem to provide an answer specific to Anaconda on MacOS
Anyone solved this?
Use the option -I/Users/myuser/anaconda/include/python2.7 in the gcc command. (That's assuming you are using python 2.7. Change the name to match the version of python that you are using.) You can use the command python-config --cflags to get the full set of recommended compilation flags:
$ python-config --cflags
-I/Users/myuser/anaconda/include/python2.7 -I/Users/myuser/anaconda/include/python2.7 -fno-strict-aliasing -I/Users/myuser/anaconda/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
However, to build the extension module, I recommend using a simple setup script, such as the following setup.py, and let distutils figure out all the compiling and linking options for you.
# setup.py
from distutils.core import setup, Extension
example_module = Extension('_example', sources=['example_wrap.c', 'example.c'])
setup(name='example', ext_modules=[example_module], py_modules=["example"])
Then you can run:
$ swig -python example.i
$ python setup.py build_ext --inplace
(Take a look at the compiler commands that are echoed to the terminal when setup.py is run.)
distutils knows about SWIG, so instead of including example_wrap.c in the list of source files, you can include example.i, and swig will be run automatically by the setup script:
# setup.py
from distutils.core import setup, Extension
example_module = Extension('_example', sources=['example.c', 'example.i'])
setup(name='example', ext_modules=[example_module], py_modules=["example"])
With the above version of setup.py, you can build the extension module with the single command
$ python setup.py build_ext --inplace
Once you've built the extension module, you should be able to use it in python:
>>> import example
>>> example.fact(5)
120
If you'd rather not use the script setup.py, here's a set of commands that worked for me:
$ swig -python example.i
$ gcc -c -I/Users/myuser/anaconda/include/python2.7 example.c example_wrap.c
$ gcc -bundle -undefined dynamic_lookup -L/Users/myuser/anaconda/lib example.o example_wrap.o -o _example.so
Note: I'm using Mac OS X 10.9.4:
$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
I am trying to get cython to realize I have a c compiler in MinGW 32-bit and I've tried everything I can find on the web but it's still not working. I am running Windows 7 Professional 64-bit. Here is what I have tried:
(1) I have Python 2.7 and I just installed MinGW with options gcc and g++ and some other options
(2) I edited the PATH environmental variable so it includes
C:\MinGW\bin;C:\MinGW\MSYS\1.0\local\bin;C:\MinGW\MSYS\1.0\bin
(3) I told Python to use MinGW as the default compiler by creating a file named
C:\Python27\Lib\distutils\distutils.cfg, containing
[build]
compiler = mingw32
(I do have MinGW32 by the way)
(4) I removed all instances of -mno-cygwin from the file C:\Python27\Lib\distutils\cygwincompiler.py
(5) I have a file called setup.py and a module called tryingcython.pyx that is written in python. My setup.py says
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
setup(
cmdclass = {'build_ext':build_ext},
ext_modules=[Extension("tryingcython",["tryingcython.pyx"])]
)
So then I open Command Prompt and get into the directory that contains setup.py and tryingcython.pyx, and I type
python setup.py build_ext --inplace --compiler=mingw32
Then it tells me:
running build_ext
skipping 'tryingcython.c' Cython extension (up-to-date)
building 'tryingcython.c' extension
gcc -mdll -O -Wall -IC:\Python27\include -IC:\Python27\PC -c tryingcython.c -o build\
temp.win32-2.7\Release\tryingcython.o
error: command 'gcc' failed: No such file or directory
So I guess Cython can't tell that I have gcc and it can't find it or what, even though I've tried about every single piece of advice I can find online for making it realize that I have MinGW which has gcc included.
Any help/additional ideas on how I can get cython to actually work would be much appreciated.
You are using exactly the same operational system and versions than me.
Try to cal gcc using:
SET input=intput.c
SET output=output.pyd
gcc -shared -IC:\Python27\include -LC:\Python27\libs -O2 -o %output% %input% -lpython27
Usually I put this call in a cythongcc.bat file, in a directory recognized by the PATH environment variable as:
gcc -shared -IC:\Python27\include -LC:\Python27\libs -O3 -mtune=native -o %1.pyd %2.c -lpython27
So that I can , from where my cython .pyx files are, just do:
cython input.pyx
cythongcc input input
To get the compiled .pyd working!
I have managed to wrap a set of Fortran 90 sources manually using f2py. To do so, I generated the signature file as explained in: http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html and I can obtain a .so which I can call from some Python interface files.
Now I want to create a package from it which would automatically build the Fortran extension. The only addition in the folder containing the Fortran sources and signature file is now a setup.py file with the following content:
from numpy.distutils.core import setup, Extension
from numpy.distutils.misc_util import Configuration
DISTNAME = 'greengard'
def configuration(parent_package='',top_path=None):
config = Configuration(DISTNAME, parent_package, top_path)
# the Fortran sources
f90_sources = ['_greengard.pyf'
'nufft1df90.f',
'nufft2df90.f',
'nufft3df90.f',
'next235.f',
'dfftpack.f',
]
config.add_extension('_greengard', f90_sources)
return config
if __name__ == "__main__":
setup(configuration=configuration)
Then activated a virtualenv and tried to install the package
python setup.py install
But get the following error in the end:
creating build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/greengard
compile options: '-Ibuild/src.linux-x86_64-2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -c'
gcc: build/src.linux-x86_64-2.7/greengard/_greengardmodule.c
gcc: build/src.linux-x86_64-2.7/fortranobject.c
compiling Fortran sources
Fortran f77 compiler: /usr/bin/gfortran -Wall -ffixed-form -fno-second-underscore -fPIC -O3 -funroll-loops
Fortran f90 compiler: /usr/bin/gfortran -Wall -fno-second-underscore -fPIC -O3 -funroll-loops
Fortran fix compiler: /usr/bin/gfortran -Wall -ffixed-form -fno-second-underscore -Wall -fno-second-underscore -fPIC -O3 -funroll-loops
compile options: '-Ibuild/src.linux-x86_64-2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -c'
error: _greengard.pyfnufft1df90.f: No such file or directory
First line after launching setup.py gave:
non-existing path in '': '_greengard.pyfnufft1df90.f'
But the setup process keeps going and the Fortran extension seem to be compiled (the displayed lines look like what I get by manually running f2py).
I tried to find a solution from the examples available online but most of them were a bit too simple to be helpful. Can someone with experience in Python packaging help me on this one please ?
After trying a bit more, I realized I was not correctly cleaning the intermediate "Build" directory created when calling the setup script. The latter must have retained one of my previous unsuccessful attempt where the path to the shared extension was set wrong.
I retried with a blank example and the installation into the site-packages of my virtualenv has been successful.