[Vm-dev] 64bit FFI?

David T. Lewis lewis at mail.msen.com
Thu Feb 12 23:00:16 UTC 2009


On Thu, Feb 12, 2009 at 10:55:51AM -0800, Andreas Raab wrote:
> 
> Well, actually, I am asking both ;-) The real problem is elsewhere. We 
> have two issues that we need to address, one is the need for 32 bit 
> libraries on a 64 bit system[*] and the other one is the need for 
> utilization of more memory. The latter is a minor issue though, the real 
> problem is the former. Because of this, I really don't care whether the 
> image is 32 or 64 bit, but I *do* care whether the library the VM links 
> against and that the plugins (FFI above all else) will work in the 64bit 
> environment.

To the best of my knowledge, on 64 bit Linux there is no way for a
64 bit program to call a library compiled for 32 bit. See for example
http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&catid=317

It might be possible to extend the FFI implementation in some way
that would allow a 64 bit VM to set up the call stack for a 32 bit
library, but I for one certainly do not know how to do this.

> So in short, a 64bit VM is a must, a 64bit image somewhat optional.
> 
> [*] Really, the problem is conflicts between the two. Some libraries 
> cannot have both 32 and 64 bit versions installed on the same box and 
> unfortunately ODBC (which we rely heavily on) is one of those.

If you just need a 64 bit VM calling various 64 bit libraries, then
the problem is straightforward, and you (or we) just need to do Mantis
7237. If you also need to call some 32 bit libraries, then the problem
is more challenging, and I do not know of a solution (*).

Dave

(*) If a vendor cannot or will not support their 32 bit and 64 bit
ODBC libraries on a single host, I would look for some creative unix
hacker to think of a workaround. There is sure to be some way to rename
things or chroot or otherwise trick the system into doing what you want,
even if the vendor is obstinate or clueless.



More information about the Vm-dev mailing list