FFI on MacOS 10.12 using Pharo 5
Locked
FFI on MacOS 10.12 using Pharo 5
 
|
Hello,
I need help rescuing code that has dependencies on FFI. I just downloaded the latest Pharo 5 vm in order to run Pharo under MacOS 10.12. Now the FFI-based code in my image no longer works (or is viewable). What worked before (for years, up through MacOS 10.11) is as follows: I have a 32-bit lib (i386) called ThePlugin.bundle (C code compiled w/ Xcode). I put it in Pharo.app/Contents/MacOS/Contents/Plugins/. The lib has a C function like: int someNumber() { return 123; } In Smalltalk I have a class ThePluginFFI with the class method: someNumber <cdecl: int 'someNumber' () module: 'ThePlugin'> ^self externalCallFailed And if I typed "ThePluginFFI someNumber" I got 123 Now I get "External module not found". If I try to view the method "someNumber" I get an MNU from RBFFLCallPragma>>selectorParts (receiver of "keywords" is nil), and the image hangs. I tried rewriting the method someNumber to look like this: someNumber ^self ffiCall: #( int someNumber() ) module: ThePlugin uniqueInstance where ThePlugin is a subclass of FFILibrary with an instance method: macModuleName ^'ThePlugin.bundle' but this still gets "External module not found" Is there some new way of doing all this? Or some new trick to loading libraries (I tried dylibs as well as bundles). I couldn't find a recent summary/update. Thanks for any help! Jay |
|
|
Previously with NativeBoost, Pharo FFI diverged from the mainline VM,
which made support from vm-devs a bit harder. In Pharo 5 we've returned to the fold with UFFI, but there are some changes required. I recorded my own learning of UFFI here... http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-1-preamble/ cheers -ben On Tue, Dec 20, 2016 at 9:41 AM, jjjhhh <[hidden email]> wrote: > Hello, > > I need help rescuing code that has dependencies on FFI. I just downloaded > the latest Pharo 5 vm in order to run Pharo under MacOS 10.12. Now the > FFI-based code in my image no longer works (or is viewable). > > What worked before (for years, up through MacOS 10.11) is as follows: > > I have a 32-bit lib (i386) called ThePlugin.bundle (C code compiled w/ > Xcode). I put it in Pharo.app/Contents/MacOS/Contents/Plugins/. > > The lib has a C function like: > int someNumber() { return 123; } > > In Smalltalk I have a class ThePluginFFI with the class method: > someNumber > <cdecl: int 'someNumber' () module: 'ThePlugin'> > ^self externalCallFailed > > And if I typed "ThePluginFFI someNumber" I got 123 > > Now I get "External module not found". If I try to view the method > "someNumber" I get an MNU from RBFFLCallPragma>>selectorParts (receiver of > "keywords" is nil), and the image hangs. > > I tried rewriting the method someNumber to look like this: > someNumber > ^self ffiCall: #( int someNumber() ) module: ThePlugin uniqueInstance > > where ThePlugin is a subclass of FFILibrary with an instance method: > macModuleName > ^'ThePlugin.bundle' > > but this still gets "External module not found" > > > Is there some new way of doing all this? Or some new trick to loading > libraries (I tried dylibs as well as bundles). > > I couldn't find a recent > summary/update. > > Thanks for any help! > Jay > > > > -- > View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
Re: FFI on MacOS 10.12 using Pharo 5
|
In reply to this post by Jay Hardesty
I recently worked with UFFI for making a shared memory library, the very first thing I have done is to do everything first with C code , to make sure things work at the C side. Its so easy to mess up things at C code. So first make sure that the library actually works, because if it does not work inside a C program it wont work with UFFI either.
The library may have to be rebuilt in Sierra , I think Sierra changed several things so just because the library worked on El Capitan does not mean it will work on Sierra. This is why its paramount you test the library inside a C application. Another thing is to make sure UFFI can locate the library , there is LibC class inside the Pharo image that gives an example on how to add paths that UFFI will search to find the library, I think its the linux side of the class but it should work the same on MacOS too. Last but not least I am not sure a bundle would work with UFFI but once more testing this with C code is the safest way to locate the problem. Old FFIs still work in Pharo 6 because there are things that UFFI cannot do like call Objective C libraries. So I doubt your problem is UFFI related most likely you need to build the library for Sierra. On Tue, Dec 20, 2016 at 3:57 AM jjjhhh <[hidden email]> wrote: Hello, |
|
|
In reply to this post by Jay Hardesty
Hi,
I never tested it with a “bundle” plugin. But if before it worked like this: someNumber <cdecl: int 'someNumber' () module: 'ThePlugin'> ^self externalCallFailed Now it should work like this: someNumber ^ self ffiCall: #(int someNumber () ) module: ‘ThePlugin’. and: a) you can do that with a FFILibrary child, in which case it will be something like this: ThePlugin>>macModuleName ^ ‘ThePlugin' someNumber ^ self ffiCall: #(int someNumber () ) module: ThePlugin. “Class reference, no need to put uniqueInstance” b) bundles needs to be put where bundles go: Pharo.app/Contents/Resources cheers, Esteban > On 20 Dec 2016, at 02:41, jjjhhh <[hidden email]> wrote: > > Hello, > > I need help rescuing code that has dependencies on FFI. I just downloaded > the latest Pharo 5 vm in order to run Pharo under MacOS 10.12. Now the > FFI-based code in my image no longer works (or is viewable). > > What worked before (for years, up through MacOS 10.11) is as follows: > > I have a 32-bit lib (i386) called ThePlugin.bundle (C code compiled w/ > Xcode). I put it in Pharo.app/Contents/MacOS/Contents/Plugins/. > > The lib has a C function like: > int someNumber() { return 123; } > > In Smalltalk I have a class ThePluginFFI with the class method: > someNumber > <cdecl: int 'someNumber' () module: 'ThePlugin'> > ^self externalCallFailed > > And if I typed "ThePluginFFI someNumber" I got 123 > > Now I get "External module not found". If I try to view the method > "someNumber" I get an MNU from RBFFLCallPragma>>selectorParts (receiver of > "keywords" is nil), and the image hangs. > > I tried rewriting the method someNumber to look like this: > someNumber > ^self ffiCall: #( int someNumber() ) module: ThePlugin uniqueInstance > > where ThePlugin is a subclass of FFILibrary with an instance method: > macModuleName > ^'ThePlugin.bundle' > > but this still gets "External module not found" > > > Is there some new way of doing all this? Or some new trick to loading > libraries (I tried dylibs as well as bundles). > > I couldn't find a recent > summary/update. > > Thanks for any help! > Jay > > > > -- > View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
Re: FFI on MacOS 10.12 using Pharo 5
|
|
Thanks Esteban, was helpful to know I had (almost!) the right syntax..
With that I was able to concentrate on the library loading - apparently using a .dylib rather than .bundle made the difference. It now works - thanks again! Jay |
Re: FFI on MacOS 10.12 using Pharo 5
|
|
In reply to this post by kilon.alios
Thanks - testing the new dylib (see response to Esteban) with a C app (command line tool) as you suggested saved me from wasting time before realizing I had a 64 vs 32 bit problem.. works now.
Cheers, Jay |
Re: FFI on MacOS 10.12 using Pharo 5
|
|
On Tue, Dec 20, 2016 at 05:23:37PM -0800, Jay Hardesty wrote:
> realizing I had a 64 vs 32 bit problem.. works now. I built a 32/64-bit combo SQLite dylib and it didn't work with Pharo on El Capitan. A pure 32-bit dylib worked. Pierce |
Re: FFI on MacOS 10.12 using Pharo 5
|
|
Thx - yes exactly the same path I took - strictly 32-bit (i386) worked, in my case on Sierra.
Jay |
Re: FFI on MacOS 10.12 using Pharo 5
|
|
Love UFFI , its opens a universe of possibilities for Pharo, an insane amount of technology that Pharo can take advantage of through it. Big thanks to Esteban and anyone that contributed to the continued evolution of FFIs. I would not be using Pharo if it was not for their efforts. On Wed, Dec 21, 2016 at 11:07 AM Jay Hardesty <[hidden email]> wrote: Thx - yes exactly the same path I took - strictly 32-bit (i386) worked, in my |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |