Compile 32bit C-lib on 64 bit

[Dan Stromberg]

On Sun, May 1, 2011 at 1:14 PM, Hegedüs Ervin <airween at gmail.com> 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 servers.
>
>
> 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, version 1 (SYSV),
> dynamically linked, stripped
>
>
> What is the correct solution?
>

The best solution is to not use a closed source, binary-only, single-sourced
(?) security library, especially if it has not been vetted by others from
outside the organization from which it was obtained.  It costs quite a bit
for a company to get such software under enough eyeballs to make it mostly
trustworthy, and it puts you at their mercy with regard to an upgrade path.
The best security-related algorithms are published and studied by many
researchers, and will have multiple interoperating implementations.

Rebuilding everything as 32 bit on your 64 bit system (if it's one of those
64 bit systems that can also conveniently run 32 bit binaries - most, but
not all, can) may be one of your better options.  This of course carries a
memory penalty, as you may end up with two copies of your python interpreter
and relevant .so's in virtual memory, and hence experience a greater
tendency to page.

There is no theoretical reason why you cannot use a 32 bit library in a 64
bit application, however it is unlikely to be simple.  You could experiment
with accessing your 32 bit library via ctypes from a 64 bit interpreter and
carefully converting pointers and integers to/from 32 bit and 64 bit (with a
significant decrease in usable address space, and the possibility of 64 bit
addresses that simply aren't convertible, especially, but not necessarily
only, once your process gets large), if you find a way of setting up an
appropriate 32 bit stack.  You could also emulate a 32 bit CPU in your 64
bit process - this too, is perhaps mostly theoretical - see qemu for an
example of something that can, EG, run x86 binaries on a sparc CPU.  In
short: "You probably could, but it might well be more trouble than it's
worth".

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.  Without
adequate vendor cooperation, and if you're truly locked in, this may
actually be one of your better options for the medium term.

Ultimately though, using something like KeyCzar or OpenSSL is probably your
best bet.  They've been scrutinized copiously, and have very low snake oil
factors.  That is, assuming KeyCzar or OpenSSL and your binary-only library
have overlapping purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110501/b804315b/attachment.html>