On 01/18/2013 02:51 PM, David T. Lewis wrote:
> On Fri, Jan 18, 2013 at 10:32:53AM +0100, G?ran Krampe wrote:
>> Hi folks!
>>
>> Just want to check with you guys how we are on the 64 bit VM front.
>>
>> I have a dynamic library that is 64 bits that I want to call using FFI
>> (any FFI!). AFAICT this is a big no, no. NB FFI doesn't do 64 bits,
>> well, in fact NB is only available in Cog and Cog is only available in
>> 32 bits, right?
>>
>> And even if Cog was available in 64 bits (Eliot?) I guess the NB FFI
>> would need work to function in 64 bits too?
>>
>> Ok, so what about the standard VM 64 bit? It doesn't seem to have a
>> working FFI plugin, so no go.
>>
>> I do not think I can get the lib in 32 bits (but I have asked upstream)
>> it is the libhyperclient.so for HyperDex (www.hyperdex.org).
>>
>> Could someone confirm the above or tell me about any other reasonable route?
>>
>> regard, G?ran
>>
>> PS. One way would be to write some wrapper around the lib in C and
>> communicate with it by some other means - like stdin/stdout etc. But...
>> uuuugly. :)
>
> Hi G?ran,
>
> This issue affects VM, a plugin in VMMaker, the image, and the external
> FFI package. I had this working in 2008 for the interpreter VM and original
> plugin, and I expect that the patches will still work today, although I
> have not verified it recently. The patches are on Mantis if you want to
> have a look at it: http://bugs.squeak.org/view.php?id=7237
>
> This overall summary is still valid:
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051595.html
>
> I still think it is really important to get this fixed, but making it
> happen will be a challenge. We are facing an increasing proliferation
> of code bases, along with a sadly reduced VM team. I'm sure we'll
> figure something out, but right now might not be the best time :(
>
> I'm not sure what your application requirements are, but if you are
> willing to compile your own VMs for this application, and if you can
> use an interpreter VM with FFI plugin, then I can probably help you
> get it working. It would be good to revisit those patches and get rid
> of the code rot anyway.

It seems I might actually be able to sidestep and get the library to 
compile in 32 bits, so I will try that first. But yes, we need to get 
going to 64 bits in general I think, it is starting to hurt. :)

But I think the current "driver" for this to happen is Cog and thus 
Eliot - he is the only person that realistically can move Cog to 64 bits 
- and Cog is the VM that most people use these days, I guess.

regards, Göran