On Sun, 2011-05-01, Hegedüs Ervin wrote:
> Hello,
>
> this is not a "clear" Python question - I've wrote a module in C,
> which uses a 3rd-party lib - it's a closed source, I just get the
> .so, .a and a header file.
>
> Looks like it works on 32bit (on my desktop), but it must be run
> on 64bit se
Hello,
thanks for all reply,
On Mon, May 02, 2011 at 03:20:40AM +0100, Nobody wrote:
> You need to build your module for a 32-bit version of Python.
ok, I believed it, I was hoping there is another solution,
> On a 64-bit system, each process is either 32-bit or 64-bit process. You
> can't mix
On Mon, May 2, 2011 at 2:34 PM, Dan Stromberg wrote:
> Another option would be to link your library into a small, 32 bit C program,
> and then establish some sort of protocol for it to communicate with your 64
> bit python interpreter - via a pipe or socket, as examples.
This is what I would reco
On Sun, May 1, 2011 at 1:14 PM, Hegedüs Ervin wrote:
> Hello,
>
> this is not a "clear" Python question - I've wrote a module in C,
> which uses a 3rd-party lib - it's a closed source, I just get the
> .so, .a and a header file.
>
> Looks like it works on 32bit (on my desktop), but it must be run
On Sun, 01 May 2011 22:14:14 +0200, Hegedüs Ervin wrote:
> When I'm compiling it on 64bit, gcc says:
>
> /usr/bin/ld: skipping incompatible /lib32/lib3rdpartyCrypt.so when
> searching for -l3rdpartyCrypt
>
> There _is_ the .so in /lib32 directory:
>
> ELF 32-bit LSB shared object, Intel 80386,
On Sun, May 1, 2011 at 4:14 PM, Hegedüs Ervin wrote:
> Hello,
>
> this is not a "clear" Python question - I've wrote a module in C,
> which uses a 3rd-party lib - it's a closed source, I just get the
> .so, .a and a header file.
>
> Looks like it works on 32bit (on my desktop), but it must be run
