On Sun, May 1, 2011 at 1:14 PM, Hegedüs Ervin <airw...@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.
-- http://mail.python.org/mailman/listinfo/python-list
