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. :) |
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. Dave |
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 |
Free forum by Nabble | Edit this page |