I have a FORTRAN code that required the following compile command
gfortran -c interp.f -ffixed-format -ffix-line-length-none
I compiled the same using f2py module in python
from numpy import f2py
f2py.compile(open('interp.f').read(),modulename='interp',extra_flags='-ffixed-format -ffix-line-length-none',verbose=0)
It is unable to compile the module. It gives an error saying invalid file format '' at '-ffized-format'
Please help
Neither -ffixed-format, nor -ffix-line-length-none seem to be valid gfortran options. Consider using -ffixed-form and -ffixed-line-length-none instead.
Related
I am trying to wrap a set of Fortran files to Python using f2py. I am using the gfortran compiler via mingw64. The sources I am trying to wrap contain Lapack functions, so I built Lapack and Blas following the "Easy windows build" instructions on this webpage: https://icl.cs.utk.edu/lapack-for-windows/lapack/#build. I am now able to compile my source file by running
gfortran foo.F90 -ffree-line-length-512 -llapack -lblas -fdec-math -Wl,-allow-multiple-definition
As you can see I need to pass a set of options, which are not really all that relevant here except for the last one -Wl,-allow-multiple-definition. I have found that if I do not include this option the file won't compile and I get a whole set of errors all ending with multiple definition of `_gfortran[...] where [...] contains some extra string, like for example _st_open'. Perhaps that last option is a bit of a hack, but at least the file compiles without issues.
However I do not know how to pass this linker option to f2py. Currently I run,
python -m numpy.f2py -llapack -lblas -c foo.F90
--fcompiler=gnu95 --compiler=mingw32 --f90flags="-ffree-line-length-512 -fdec-math -Wl,-allow-multiple-definition" -m foo_py
But this doesn't seem to do anything, I just get the same multiple definition error as if the linker flag wasn't included. So what syntax should I use?
Thanks!
EDIT: After some extensive googling it seems like f2py contains no option to pass linker flags to the compiler. So now I am wondering if there is some way to force the allow-multiple-definition option on the compiler globally.
I think the error itself must somehow originate in how I have built LAPACK and BLAS. Similar errors have been reported before, see https://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=4&t=5315, but seemingly only in the built process and not during a fortran compile. Would there be alternative ways to build LAPACK such that I can easily incorporate it with gfortran?
Did you have a look at this: how to tell f2py module to look in current directory for shared object dependency
There the following is suggested:
set env variable export LDFLAGS=-Wl,-rpath=.
set env variable export NPY_DISTUTILS_APPEND_FLAGS=1
upgrade numpy to 1.16.0 or greater
I need to write a python wrapper for an existing C++ Module. First I tested the procedere with this basic example (which now actually works fine): C++ - Python Binding with ctypes - Return multiple values in function
Now I tried to change the setting: I want to use the existing lib instead of my single cpp file. I tried it with this:
g++ -c -I. -fPIC projectionWrapper.cpp -o projectionWrapper.o
g++ -shared -Wl,-soname,libproj.so
-L./build/liborig_interface.a,./build/liborig_base.a
-o libproj.so projectionWrapper.o
I wanted to link against both .a files from the given library with the -L command. I don't get any errors on that, but when I try to import the module via ipython, I get this:
import myprojection # I load libproj.so in this python file
OSError: ./libproj.so: undefined symbol: _Z29calibration_loadPKcjbP14camera_typetS2_
There is a function "calibration_load", as well a "camera_type" in the original framework. But I have no clue where the cryptic things in between come from.
Sorry for my vague explanation, I tried to explain it as good as possible, but a C++ Wrapper is not one of my topics where I feel "at home".
The problem is that you're not linking against the external library that you use in your C++ code; add -l<library> to your second g++ call.
g++ -shared projectionWrapper.o
-L./build/base -L./build/interface
-loriginterface -lorigbase
-Wl,-soname,libproj.so
-o libproj.so
did the job. Thanks for the hint that I actually didn't link the libraries as I only used the -L option.
Moreover the order of the options was wrong. I had to state "projectionWrapper.o" right at the beginning, as well as "-loriginterface" before "-lorigbase". This was answered here: "undefined reference" when linking against a static library
(complete name of the libs are: liboriginterface.a and liborigbase.a)
I have two F90 files that I want to use with python, so I'm using f2py to compile them (together) and result a python module, I'm doing it like this:
f2py -c ControlParameters.F90 vector.F90 -m test
When I do this, everything is fine, and I can use functions and subroutines from those files with python.
But now, I need to use f2py with those two files, adding a couple of libraries, like -liomp5 or -lzmumps, I get the python module like in the upper case, but when I try to import it from python I have the following error:
ImportError: /opt/intel/composer_xe_2013.1.117/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so: undefined symbol: MPI_Finalize
There are some libraries that cannot be used with f2py?
I have a working c++ code that I want to wrap into a python module on Windows XP and Python 2.7. I have never done this before, so I looked into swig and distutils.
I created an interface file and a setup.py and compiled using
python setup.py build_ext -c mingw32
The script creates a module_wrap.cpp from my module.i and module.cpp file, and then creates a module_wrap.o and a module.o. The creation of module.o creates a bunch of Warnings for unused variables and deprecated char*, but it seems to work. Because the C++-code is not mine, I don't really want to get into these right now.
The last step is executing
g++.exe -shared -s build\temp.win32-2.7\Release\module_wrap.o build\temp.win32-2.7\Release\module.o build\temp.win32-2.7\Release\_module.def -LC:\Programme\Python27\libs -LC:\Programme\Python27\PCbuild -lpython27 -o build\lib.win32-2.7\_module.pyd
I get
Cannot export init_module: symbol not defined
error: command 'g++' failed with exit status 1
I googled a lot to this now, and I just can not find a solution to this problem. The previously created _module.def seems to try to export this init since it contains
LIBRARY _module.pyd
EXPORTS
init_module
Obviously this doesn't work, but I have no idea why. Can anyone help me out here?
I figured it out. The problem was the (not posted) interface file module.i for swig. There I named the module %module usemodule, whereas in the setup.py i named the module name=module. This way swig created an init_function, that did not match the name the created module was expecting it. In the end: just a typo...
Thanks for your support nevertheless!
I am having difficulty with getting a f2py compiled module work in Python.
I have a piece of software written in Fortran that compiles well on a Linux 64bit machine.
Further on F2Py compiles a Python module that uses Fortran bits as well.
Here is how the Python module is compiled:
f2py --fcompiler=gfortran -I"path-to-dir-with-mod-files" -c -m mod_landems mod_landem.f90
But once I want to import that module I get an error (in Ipython):
----> 1 import mod_landems
ImportError: ./mod_landems.so: undefined symbol: __nesdis_landem_module_MOD_nesdis_landem
To be honest I am confused with this error. Search did not help much so I need to ask you here: how can I possibly make it work? If I put the python module code in the same directory as where the mod files are it produces same error message.
Here is a piece of my (primitive) code:
module n_landem
implicit none
! INPUT VARIABLES
real(8) Angle
real(8) Sm_Content
real(8) Veg_Frac
real(8) Soil_Temp
real(8) Land_Temp
real(8) Snow_Depth
real(8) Frequency
! OUTPUT VARIABLES
real(8) Emis_H
real(8) Emis_V
contains
subroutine landem
USE NESDIS_LANDEM_MODULE
USE TYPE_KINDS, ONLY : fp
call NESDIS_LandEM(Angle,Frequency,Sm_Content,Veg_Frac,Soil_Temp,Land_Temp,Snow_Depth,Emis_H,Emis_V)
end subroutine landem
end module n_landem
If I recall correctly some time ago this module was importable, but can't seem to make it work on either debian64 installation or debian32bit computer.
in your f2py call, you have to pass the libraries you are linking explicitly with '-l', the same you would pass it to your Fortran compiler (i.e. gfortran). Therefore, does
f2py -c --fcompiler=gfortran -I"path-to-dir-with-mod-files" --fcompiler=gfortran -I"path-to-dir-with-mod-files" -lNESDIS_LandEM_Module -m mod_landems mod_landem.f90 -m mod_landems mod_landem.f90
work for you ?
Best,
Max.
I'm working on a similar project and too am new to Fortran. Using the reference below I found that you import the fortran module just as you would import a library and then call a function similarly.
http://cens.ioc.ee/projects/f2py2e/usersguide/#the-quick-and-smart-way