Calling routines from a Fortran library using python
Hi all, I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ? Any pointer would be appreciated. Thanks in advance. Nils
Nils Wagner wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Is there any kind of interface (.h, etc...) ? If this is a proprietary library, there has to be something so that it can be called from C, and anything that can be called from C can be called from python. If you don't know at least the functions signatures, it will be very difficult (you would have to disassemble the code to find how the functions are called, etc...). cheers, David
On Thu, 18 Feb 2010 18:32:18 +0900 David Cournapeau <david@silveregg.co.jp> wrote:
Nils Wagner wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Is there any kind of interface (.h, etc...) ? If this is a proprietary library, there has to be something so that it can be called from C, and anything that can be called from C can be called from python. If you don't know at least the functions signatures, it will be very difficult (you would have to disassemble the code to find how the functions are called, etc...).
cheers,
David
Hi David, you are right. It's a proprietary library. I found a header file (*.h) including prototype declarations of externally callable procedures. How can I proceed ? Thank you again. Cheers, Nils
Nils Wagner <nwagner <at> iam.uni-stuttgart.de> writes:
Hi David,
you are right. It's a proprietary library. I found a header file (*.h) including prototype declarations of externally callable procedures.
How can I proceed ?
Apparently you can use ctypes to access fortran libraries. See the first paragraph of: http://www.sagemath.org/doc/numerical_sage/ctypes.html You may have to convert the .a library to a .so library. Neil
You may have to convert the .a library to a .so library.
And this is where I hope that the library is compiled with fPIC (which is generally not the case for static libraries). If it is not the case, you will not be able to compile it as a shared library and thus not be able to use it from Python :| Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
Matthieu Brucher wrote:
If it is not the case, you will not be able to compile it as a shared library and thus not be able to use it from Python :|
maybe not directly with ctypes, but you should be able to call it from Cython (or SWIG, or custom C code), and statically link it. What about f2py? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Christopher Barker wrote:
Matthieu Brucher wrote:
If it is not the case, you will not be able to compile it as a shared library and thus not be able to use it from Python :|
maybe not directly with ctypes, but you should be able to call it from Cython (or SWIG, or custom C code), and statically link it.
If it is not compiled with -fPIC, you can't statically link it into any shared library, it has to be statically linked into the final executable (so the standard /usr/bin/python will never work). Dag Sverre
Dag Sverre Seljebotn wrote:
If it is not compiled with -fPIC, you can't statically link it into any shared library, it has to be statically linked into the final executable (so the standard /usr/bin/python will never work).
Shows you what I (don't) know! The joys of closed-source software! On a similar topic -- is it possible to convert a *.so to a static lib? (on OS-X)? I did a bunch a googling a while back, and couldn't figure it out. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
2010/2/18 Christopher Barker <Chris.Barker@noaa.gov>:
Dag Sverre Seljebotn wrote:
If it is not compiled with -fPIC, you can't statically link it into any shared library, it has to be statically linked into the final executable (so the standard /usr/bin/python will never work).
Shows you what I (don't) know!
The joys of closed-source software!
On a similar topic -- is it possible to convert a *.so to a static lib? (on OS-X)? I did a bunch a googling a while back, and couldn't figure it out.
I don't think you can. A static library is nothing more than an archive of object files (a Fortran module file is the same BTW), a dynamic library is one big object with every link created. Going from the latter to the former cannot be easilly done. Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
On Thu, 18 Feb 2010 10:15:51 +0000 (UTC) Neil Crighton <neilcrighton@gmail.com> wrote:
Nils Wagner <nwagner <at> iam.uni-stuttgart.de> writes:
Hi David,
you are right. It's a proprietary library. I found a header file (*.h) including prototype declarations of externally callable procedures.
How can I proceed ?
Apparently you can use ctypes to access fortran libraries. See the first paragraph of:
http://www.sagemath.org/doc/numerical_sage/ctypes.html
You may have to convert the .a library to a .so library.
Neil
How do I convert the .a library to a .so library ? Nils
Nils Wagner wrote:
How do I convert the .a library to a .so library ?
You first "uncompress" the .a into a temporary directory, with ar x on Linux. Then, you group the .o together with gfortran -shared $LIST_OF_OBJECT + a few options. You can also look at how Atlas does it in its makefile. As Matthieu mentioned, if the .o are not compiled with -fPIC, you are screwed on 64 bits architectures (unless you statically link numpy in your python interpreter, but I doubt you want to go that road). It would be somewhat surprising if your vendor did not shared libraries available, though. cheers, David
On Thu, 18 Feb 2010 19:30:10 +0900 David Cournapeau <david@silveregg.co.jp> wrote:
Nils Wagner wrote:
How do I convert the .a library to a .so library ?
You first "uncompress" the .a into a temporary directory, with ar x on Linux. Then, you group the .o together with gfortran -shared $LIST_OF_OBJECT + a few options. You can also look at how Atlas does it in its makefile.
As Matthieu mentioned, if the .o are not compiled with -fPIC, you are screwed on 64 bits architectures (unless you statically link numpy in your python interpreter, but I doubt you want to go that road). It would be somewhat surprising if your vendor did not shared libraries available, though.
cheers,
David
Ok I have extracted the *.o files from the static library. Applying the file command to the object files yields ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped What's that supposed to mean ? Nils
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so) Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line. Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried gfortran -shared *.o -o libmysharedlibrary.so /usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC dscpde.o: could not read symbols: Bad value Any idea ? Nils
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried
gfortran -shared *.o -o libmysharedlibrary.so
/usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
The message is pretty explicit: it is not compiled with -fPIC, there is nothing you can do, short of requesting a shared library from the software vendor. David
David Cournapeau wrote:
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried
gfortran -shared *.o -o libmysharedlibrary.so
/usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
The message is pretty explicit: it is not compiled with -fPIC, there is nothing you can do, short of requesting a shared library from the software vendor.
Well, I think one can make a static executable with C or Cython and embed the Python interpreter. But it is pretty complicated stuff, and requesting a shared library is vastly preferable. Dag Sverre
On Thu, 18 Feb 2010 15:32:12 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
David Cournapeau wrote:
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried
gfortran -shared *.o -o libmysharedlibrary.so
/usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
The message is pretty explicit: it is not compiled with -fPIC, there is nothing you can do, short of requesting a shared library from the software vendor.
Well, I think one can make a static executable with C or Cython and embed the Python interpreter. But it is pretty complicated stuff, and requesting a shared library is vastly preferable.
Dag Sverre
Can you shed light on your approach ? Nils
Nils Wagner wrote:
On Thu, 18 Feb 2010 15:32:12 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
David Cournapeau wrote:
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried
gfortran -shared *.o -o libmysharedlibrary.so
/usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
The message is pretty explicit: it is not compiled with -fPIC, there is nothing you can do, short of requesting a shared library from the software vendor.
Well, I think one can make a static executable with C or Cython and embed the Python interpreter. But it is pretty complicated stuff, and requesting a shared library is vastly preferable.
Dag Sverre
Can you shed light on your approach ?
If one searches the Cython lists (gmane.org) for "embedding python interpreter" it should give some hints as to how to compile a Cython .pyx module into an executable (so you get an executable which links in Python, and which has to be used instead of Python). There's even some flags in Cython to do this easily. Ask on the Cython list for more info, I don't know more myself. Then, one could link the static Fortran library into the resulting application statically, and use Cython to call the exported functions in the Fortran library. But, the result is a standalone application, one can't use it with the standard Python interpreter (although one can import in any .py files etc. as usual). Dag Sverre
Dag Sverre Seljebotn wrote:
Well, I think one can make a static executable with C or Cython and embed the Python interpreter.
Yes, it is possible, but I think it is fair to say that if you don't know how to write a C extension, statically build numpy into python would be daunting :) David
On Thu, 18 Feb 2010 22:29:39 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
On Thu, 18 Feb 2010 11:55:07 +0100 Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
Ok I have extracted the *.o files from the static library.
Applying the file command to the object files yields
ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
What's that supposed to mean ?
It means that each object file is an object file compiled with -fPIC, so you just have to make a shared library (gfortran -shared *.o -o libmysharedlibrary.so)
Then, you can try to open the library with ctypes. If something is lacking, you may have to add -lsome_library to the gfortran line.
Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
O.k. I tried
gfortran -shared *.o -o libmysharedlibrary.so
/usr/bin/ld: dxop.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
The message is pretty explicit: it is not compiled with -fPIC, there is nothing you can do, short of requesting a shared library from the software vendor.
David
Hi, Meanwhile I received a static library (including -fPIC support) from the software vendor. Now I have used ar x test.a gfortran -shared *.o -o libtest.so -lg2c to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp Now I am able to load the shared library from ctypes import * my_lib = CDLL('test.so') What are the next steps to use the library functions within python ? Nils
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library: http://python.net/crew/theller/ctypes/tutorial.html But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received. cheers, David
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
g77 -shared *.o -o libtest.so -lg2c failed with /usr/lib/64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc_s IIRC that is a known bug related to SuSE . Are you aware of a solution ? Cheers, Nils
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Just to play it safe Consider extern void dsio (int* const,const char* const, int* const,const size_t); extern void dsrhed (const int* const,const int* const,void* const, const int* const,const int* const,int* const, int* const,int* const,int* const,int* const, int* const,int* const,int* const); from ctypes import * my_lib = CDLL('libtest.so') How do I call the functions within python I mean what arguments are needed ? my_lib.dsio( ) my_lib.dsrhed( ) Thank you very much for your help. Cheers, Nils
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all, I tried to run the following script. The result is a segmentation fault. Did I use byref correctly ? from ctypes import * my_dsio = CDLL('libdsio20_gnu4.so') # loading dynamic link libraries # # FORTRAN : CALL DSIO(JUNCAT,FDSCAT,IERR) # # int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; # Word BUF[100],HEAD[30]; # char *PATH,*STRING; # char *PGNAME,*DATE,*TIME,*TEXT; # int LHEAD=30; # # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); # IERR = c_int() FDSCAT = c_char_p('dscat.ds') JUNCAT = c_int() LDSNCAT = c_int(len(FDSCAT.value)) print print 'LDSNCAT', LDSNCAT.value print 'FDSCAT' , FDSCAT.value , len(FDSCAT.value) my_dsio.dsio(byref(JUNCAT),byref(FDSCAT),byref(IERR),byref(LDSNCAT)) # segmentation fault print IERR.value Any idea ? Nils
Nils Wagner wrote:
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all,
I tried to run the following script. The result is a segmentation fault. Did I use byref correctly ?
from ctypes import * my_dsio = CDLL('libdsio20_gnu4.so') # loading dynamic link libraries # # FORTRAN : CALL DSIO(JUNCAT,FDSCAT,IERR) # # int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; # Word BUF[100],HEAD[30]; # char *PATH,*STRING; # char *PGNAME,*DATE,*TIME,*TEXT; # int LHEAD=30; # # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); #
IERR = c_int() FDSCAT = c_char_p('dscat.ds') JUNCAT = c_int() LDSNCAT = c_int(len(FDSCAT.value)) print print 'LDSNCAT', LDSNCAT.value print 'FDSCAT' , FDSCAT.value , len(FDSCAT.value)
my_dsio.dsio(byref(JUNCAT),byref(FDSCAT),byref(IERR),byref(LDSNCAT)) # segmentation fault print IERR.value
Any idea ?
You shouldn't have byref on FDSCAT nor LDSNCAT, as explained by this line: # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); Dag Sverre
On Thu, 11 Mar 2010 13:01:33 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
Nils Wagner wrote:
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all,
I tried to run the following script. The result is a segmentation fault. Did I use byref correctly ?
from ctypes import * my_dsio = CDLL('libdsio20_gnu4.so') # loading dynamic link libraries # # FORTRAN : CALL DSIO(JUNCAT,FDSCAT,IERR) # # int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; # Word BUF[100],HEAD[30]; # char *PATH,*STRING; # char *PGNAME,*DATE,*TIME,*TEXT; # int LHEAD=30; # # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); #
IERR = c_int() FDSCAT = c_char_p('dscat.ds') JUNCAT = c_int() LDSNCAT = c_int(len(FDSCAT.value)) print print 'LDSNCAT', LDSNCAT.value print 'FDSCAT' , FDSCAT.value , len(FDSCAT.value)
my_dsio.dsio(byref(JUNCAT),byref(FDSCAT),byref(IERR),byref(LDSNCAT)) # segmentation fault print IERR.value
Any idea ?
You shouldn't have byref on FDSCAT nor LDSNCAT, as explained by this line:
# C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT));
Dag Sverre
Sorry, I am newbie to C. What is the correct way ? Nils
Nils Wagner wrote:
On Thu, 11 Mar 2010 13:01:33 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
Nils Wagner wrote:
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all,
I tried to run the following script. The result is a segmentation fault. Did I use byref correctly ?
from ctypes import * my_dsio = CDLL('libdsio20_gnu4.so') # loading dynamic link libraries # # FORTRAN : CALL DSIO(JUNCAT,FDSCAT,IERR) # # int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; # Word BUF[100],HEAD[30]; # char *PATH,*STRING; # char *PGNAME,*DATE,*TIME,*TEXT; # int LHEAD=30; # # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); #
IERR = c_int() FDSCAT = c_char_p('dscat.ds') JUNCAT = c_int() LDSNCAT = c_int(len(FDSCAT.value)) print print 'LDSNCAT', LDSNCAT.value print 'FDSCAT' , FDSCAT.value , len(FDSCAT.value)
my_dsio.dsio(byref(JUNCAT),byref(FDSCAT),byref(IERR),byref(LDSNCAT)) # segmentation fault print IERR.value
Any idea ?
You shouldn't have byref on FDSCAT nor LDSNCAT, as explained by this line:
# C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT));
Dag Sverre
Sorry, I am newbie to C. What is the correct way ?
my_dsio.dsio(byref(JUNCAT),FDSCAT,byref(IERR),LDSNCAT) Dag
On Thu, 11 Mar 2010 13:42:43 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
Nils Wagner wrote:
On Thu, 11 Mar 2010 13:01:33 +0100 Dag Sverre Seljebotn <dagss@student.matnat.uio.no> wrote:
Nils Wagner wrote:
On Mon, 22 Feb 2010 22:18:23 +0900 David Cournapeau <cournape@gmail.com> wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
ar x test.a gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c was necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if compiling with gfortran. I am afraid that you got a library compiled with g77. If that's the case, you should use g77 and not gfortran. You cannot mix libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import * my_lib = CDLL('test.so')
What are the next steps to use the library functions within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77 and gfortran, pass everything by reference. To make sure to pass the right arguments, I strongly suggest to double check with the .h you received.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all,
I tried to run the following script. The result is a segmentation fault. Did I use byref correctly ?
from ctypes import * my_dsio = CDLL('libdsio20_gnu4.so') # loading dynamic link libraries # # FORTRAN : CALL DSIO(JUNCAT,FDSCAT,IERR) # # int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; # Word BUF[100],HEAD[30]; # char *PATH,*STRING; # char *PGNAME,*DATE,*TIME,*TEXT; # int LHEAD=30; # # C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT)); #
IERR = c_int() FDSCAT = c_char_p('dscat.ds') JUNCAT = c_int() LDSNCAT = c_int(len(FDSCAT.value)) print print 'LDSNCAT', LDSNCAT.value print 'FDSCAT' , FDSCAT.value , len(FDSCAT.value)
my_dsio.dsio(byref(JUNCAT),byref(FDSCAT),byref(IERR),byref(LDSNCAT)) # segmentation fault print IERR.value
Any idea ?
You shouldn't have byref on FDSCAT nor LDSNCAT, as explained by this line:
# C : DSIO(&JUNCAT,FDSCAT,&IERR,strlen(FDSCAT));
Dag Sverre
Sorry, I am newbie to C. What is the correct way ?
my_dsio.dsio(byref(JUNCAT),FDSCAT,byref(IERR),LDSNCAT)
Dag
Great. It works like a charme. How can I "translate" the following C-code into Python ? I don't know how to handle HEAD and memcpy ? Any pointer would be appreciated. Thanks in advance. typedef union { int i; float f; char c[4]; } Word; int I,J,K,N,IDE,IA,IE,IERR,JUNIT,JUNCAT,NDATA,NREC,LREADY,ONE=1; Word BUF[100],HEAD[30]; for (I=5;I<LHEAD;I++) HEAD[I].i = 0; HEAD[ 0].i = 1; HEAD[ 1].i = LHEAD + NDATA*7; HEAD[ 2].i = LHEAD; HEAD[ 3].i = NDATA; HEAD[ 4].i = 7; memcpy (HEAD[ 7].c,"DSIO",4); memcpy (HEAD[ 8].c,"TEST",4); memcpy (HEAD[ 9].c,"NPCO",4); memcpy (HEAD[10].c," ",4); memcpy (HEAD[11].c,"DSIO",4); HEAD[20].i = 1; HEAD[21].i = NDATA; STRING = "MM RAD"; DSEINH(STRING,&HEAD[24].i,&ONE, strlen(STRING));
Nils Wagner wrote:
On Thu, 18 Feb 2010 18:32:18 +0900 David Cournapeau <david@silveregg.co.jp> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ? Is there any kind of interface (.h, etc...) ? If this is a proprietary
Nils Wagner wrote: library, there has to be something so that it can be called from C, and anything that can be called from C can be called from python. If you don't know at least the functions signatures, it will be very difficult (you would have to disassemble the code to find how the functions are called, etc...).
cheers,
David
Hi David,
you are right. It's a proprietary library. I found a header file (*.h) including prototype declarations of externally callable procedures.
How can I proceed ?
Exactly as you would do for a C library (ctypes, cython, by hand, swig, etc...). Once you have the header (plus the C->Fortran ABI convention, which depend on your compilers and platforms), it is exactly as calling a C function in a C library, cheers, David
On Thu, 18 Feb 2010 19:21:03 +0900 David Cournapeau <david@silveregg.co.jp> wrote:
Nils Wagner wrote:
On Thu, 18 Feb 2010 18:32:18 +0900 David Cournapeau <david@silveregg.co.jp> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ? Is there any kind of interface (.h, etc...) ? If this is a proprietary
Nils Wagner wrote: library, there has to be something so that it can be called from C, and anything that can be called from C can be called from python. If you don't know at least the functions signatures, it will be very difficult (you would have to disassemble the code to find how the functions are called, etc...).
cheers,
David
Hi David,
you are right. It's a proprietary library. I found a header file (*.h) including prototype declarations of externally callable procedures.
How can I proceed ?
Exactly as you would do for a C library (ctypes, cython, by hand, swig, etc...). Once you have the header (plus the C->Fortran ABI convention, which depend on your compilers and platforms), it is exactly as calling a C function in a C library,
cheers,
David
To be honest that's over my head. I mean I have never used C before. Where can I find a step-by-step example for my task ? Nils
Hi Nils, I've not tried it, but you might be able to interface with f2py your own fortran subroutine that calls the library. Then issue the f2py command with extra arguments -l<libname> -L<directory with lib>. See section 5 of http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#command-f2py --George. On 18 February 2010 09:18, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Any pointer would be appreciated.
Thanks in advance.
Nils _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
If header files are provided, the work done by f2py is almost done. But you don't know the real Fortran interface, so you still have to use ctypes over f2py. Matthieu 2010/2/18 George Nurser <gnurser@googlemail.com>:
Hi Nils, I've not tried it, but you might be able to interface with f2py your own fortran subroutine that calls the library. Then issue the f2py command with extra arguments -l<libname> -L<directory with lib>.
See section 5 of http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#command-f2py
--George.
On 18 February 2010 09:18, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Any pointer would be appreciated.
Thanks in advance.
Nils _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
I'm suggesting writing a *new* Fortran interface, coupled with f2py. The original library just needs to be linked to the new .so generated by f2py. I am hoping (perhaps optimistically) that can be done in the Fortran compilation... --George. On 18 February 2010 10:56, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
If header files are provided, the work done by f2py is almost done. But you don't know the real Fortran interface, so you still have to use ctypes over f2py.
Matthieu
2010/2/18 George Nurser <gnurser@googlemail.com>:
Hi Nils, I've not tried it, but you might be able to interface with f2py your own fortran subroutine that calls the library. Then issue the f2py command with extra arguments -l<libname> -L<directory with lib>.
See section 5 of http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#command-f2py
--George.
On 18 February 2010 09:18, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Any pointer would be appreciated.
Thanks in advance.
Nils _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
If Nils has no access to the Fortran interface (and I don't think he has, unless there is some .mod file somewhere?), he shouldn't use f2py. Even if you know that the Fortran routine is named XXX, you don't know how the arguments must be given. Addressing the C interface directly is much safer. Matthieu 2010/2/18 George Nurser <gnurser@googlemail.com>:
I'm suggesting writing a *new* Fortran interface, coupled with f2py. The original library just needs to be linked to the new .so generated by f2py. I am hoping (perhaps optimistically) that can be done in the Fortran compilation...
--George.
On 18 February 2010 10:56, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
If header files are provided, the work done by f2py is almost done. But you don't know the real Fortran interface, so you still have to use ctypes over f2py.
Matthieu
2010/2/18 George Nurser <gnurser@googlemail.com>:
Hi Nils, I've not tried it, but you might be able to interface with f2py your own fortran subroutine that calls the library. Then issue the f2py command with extra arguments -l<libname> -L<directory with lib>.
See section 5 of http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#command-f2py
--George.
On 18 February 2010 09:18, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but no source files. How can I call routines from that library using python ?
Any pointer would be appreciated.
Thanks in advance.
Nils _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
participants (8)
-
Christopher Barker -
Dag Sverre Seljebotn -
David Cournapeau -
David Cournapeau -
George Nurser -
Matthieu Brucher -
Neil Crighton -
Nils Wagner