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 -- 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.
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 <jayhardesty@gmail.com> 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.
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 <jayhardesty@gmail.com> 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.
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 -- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927702.htm... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Thx - yes exactly the same path I took - strictly 32-bit (i386) worked, in my case on Sierra. Jay -- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927740.htm... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <jayhardesty@gmail.com> wrote:
Thx - yes exactly the same path I took - strictly 32-bit (i386) worked, in my case on Sierra. Jay
-- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927740.htm... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <jayhardesty@gmail.com> 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.
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 -- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927700.htm... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (6)
-
Ben Coman -
Dimitris Chloupis -
Esteban Lorenzano -
Jay Hardesty -
jjjhhh
-
Pierce Ng