On Thu, 11 Mar 2010 13:42:43 +0100
Dag Sverre Seljebotn
wrote:
> Nils Wagner wrote:
>> On Thu, 11 Mar 2010 13:01:33 +0100
>> Dag Sverre Seljebotn
>> wrote:
>>
>>> Nils Wagner wrote:
>>>
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau wrote:
>
Nils Wagner wrote:
> On Thu, 11 Mar 2010 13:01:33 +0100
> Dag Sverre Seljebotn
> wrote:
>
>> Nils Wagner wrote:
>>
>>> On Mon, 22 Feb 2010 22:18:23 +0900
>>> David Cournapeau wrote:
>>>
>>>
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
wrote:
On Thu, 11 Mar 2010 13:01:33 +0100
Dag Sverre Seljebotn
wrote:
> Nils Wagner wrote:
>> On Mon, 22 Feb 2010 22:18:23 +0900
>> David Cournapeau wrote:
>>
>>> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
>>> wrote:
>>>
>>>
ar x test.a
gfortran -shared *.o -o libtest.so -lg2c
Nils Wagner wrote:
> On Mon, 22 Feb 2010 22:18:23 +0900
> David Cournapeau wrote:
>
>> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
>> wrote:
>>
>>
>>> ar x test.a
>>> gfortran -shared *.o -o libtest.so -lg2c
>>>
>>> to build a shared library. The additional option -lg2c
>>> was
>>> n
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
> 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
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
> 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
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau wrote:
> On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
> 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
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
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
On Thu, 18 Feb 2010 22:29:39 +0900
David Cournapeau wrote:
> On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner
> wrote:
>> On Thu, 18 Feb 2010 11:55:07 +0100
>> Matthieu Brucher wrote:
Ok I have extracted the *.o files from the static
library.
Applying the file command to the o
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 :)
Davi
2010/2/18 Christopher Barker :
> 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
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
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 cu
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
Nils Wagner wrote:
> On Thu, 18 Feb 2010 15:32:12 +0100
> Dag Sverre Seljebotn
> wrote:
>
>> David Cournapeau wrote:
>>
>>> On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner
>>> wrote:
>>>
>>>
On Thu, 18 Feb 2010 11:55:07 +0100
Matthieu Brucher wrote:
On Thu, 18 Feb 2010 15:32:12 +0100
Dag Sverre Seljebotn
wrote:
> David Cournapeau wrote:
>> On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner
>> wrote:
>>
>>> On Thu, 18 Feb 2010 11:55:07 +0100
>>> Matthieu Brucher wrote:
>>>
> Ok I have extracted the *.o files from the static
>
David Cournapeau wrote:
> On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner
> wrote:
>
>> On Thu, 18 Feb 2010 11:55:07 +0100
>> Matthieu Brucher wrote:
>>
Ok I have extracted the *.o files from the static
library.
Applying the file command to the object files yields
On Thu, Feb 18, 2010 at 10:22 PM, Nils Wagner
wrote:
> On Thu, 18 Feb 2010 11:55:07 +0100
> Matthieu Brucher 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, versi
On Thu, 18 Feb 2010 11:55:07 +0100
Matthieu Brucher 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
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.
Ma
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 wrote:
> I
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 :
> Hi Nils,
> I've not tried it, but you might be able to interface with f2py your
> own fortran subrouti
> 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
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
-L.
See section 5 of
http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#command-f2py
--George.
On 18 February 20
On Thu, 18 Feb 2010 19:30:10 +0900
David Cournapeau 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_OBJ
On Thu, 18 Feb 2010 19:21:03 +0900
David Cournapeau wrote:
> Nils Wagner wrote:
>> On Thu, 18 Feb 2010 18:32:18 +0900
>> David Cournapeau wrote:
>>> Nils Wagner wrote:
Hi all,
I have a static library (*.a) compiled by gfortran but
no
source files.
How can I ca
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.
On Thu, 18 Feb 2010 10:15:51 + (UTC)
Neil Crighton wrote:
> Nils Wagner 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 pro
> 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 Pytho
Nils Wagner wrote:
> On Thu, 18 Feb 2010 18:32:18 +0900
> David Cournapeau 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 inte
On Thu, 18 Feb 2010 18:32:18 +0900
David Cournapeau 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
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 call
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
___
33 matches
Mail list logo
