Dear All
I am writing primitives to port Stephen Pope’s portmidi_lite VisualWorks plugin to Squeak (on Mac Intel for now). To test everything possible before linking to the portmidi library, I wrote a series of test plugins using the arguments, return types, and pointer manipulation etc required by portmidi_lite. These show that the primitives do the appropriate proxyinterpreter stack manipulation, type conversion and object creation while avoiding garbage collection, and generally exchange data just fine with the test plugins. But to transfer this to portmidi_lite, the portmidi library must be linked in. After removing the VW-specific includes from Stephen's portmidi_lite.c (renamed as noted below) and supplying the necessary .h’s , the make compiles and links without error. However, the plugin then fails to load at runtime. More specifically, when I run the automatically generated make to rebuild the VM/plugins and to link my slang-generated glue code to portmidi_lite.c and to the portmidi library, this all runs to completion and compiles with no errors. The plugin is created and put in the right place (as an external) and looks sensible via nm. However, the plugin fails to load at run-time. On attempting to load the plugin, Squeak complains to the console “ioLoadModule could not load shared object: /Users/simon/squeak/build/Squeak-3.9-12.app/Contents/MacOS/PortMidiLitePlugin.“ This message originates from vm/dlfcn-dyld.c , where it wraps a Mach error code NSObjectFileImageInappropriateFile – ‘file was not an appropriate type of object file’. In the Makefile.inc for linking the portmidi plugin, I have PLIBS=$PLIBS -L/Users/simon/squeak/platforms/unix/plugins/PortMidiLitePlugin/i386 The folder i386 contains libportmidi.a pmmac.o pmmacosxcm.o pmutil.o portmidi.LinkFileList portmidi.o ptmacosx_mach.o The contents of this folder is a fresh build of the portmidi library for intel Mac created using the Xcode project provided by the portmidi guys. (The previous attempt, using just the single file libportmidi.a in this folder gave the same result.) For completeness, up a level at Users/simon/squeak/platforms/unix/plugins/PortMidiLitePlugin we have the following files SirenDLLCC.h (this just includes debug defines) portmidi.h portmidi_lite.h porttime.h spPortMidiLitePlugin.c (a renamed version of portmidi_lite.c with the VW includes removed – this has includes for the four .h’s) Any thoughts would be greatly appreciated. Simon Holland (Cross posted to squeak audio and vw-dev) |
Can anyone point to any examples or info on how to
link a dynamic library into a Squeak plugin build on Mac Intel? None of the following work PLIBS=$PLIBS /Users/simon/squeak/platforms/unix/plugins/PortMidiLitePlugin/i386/libportmidi.dylib PLIBS=$PLIBS /usr/local/lib/libportmidi.dylib PLIBS=$PLIBS -dynamiclib -Wl,-single_module -Wl,-install_name, /usr/local/lib/libportmidi.dylib PLIBS=$PLIBS -dynamiclib -Wl,-single_module -Wl,-install_name, lportmidi PLIBS=$PLIBS lportmidi (They compile fine but fail to load) libportmidi.dylib is installed in /usr/lib and the environment variable DYLD_LIBRARY_PATH is set to /usr/local/lib Recasting the plugin as a command line C application, and dropping the relevant dylib into the XCode window works with no bother. Cheers Simon |
On Aug 25, 2007, at 16:54 , Simon Holland wrote: > > > Can anyone point to any examples or info on how to > link a dynamic library into a Squeak plugin build on Mac Intel? > > None of the following work > > PLIBS=$PLIBS > /Users/simon/squeak/platforms/unix/plugins/PortMidiLitePlugin/i386/ > libportmidi.dylib > PLIBS=$PLIBS /usr/local/lib/libportmidi.dylib > PLIBS=$PLIBS -dynamiclib -Wl,-single_module -Wl,-install_name, > /usr/local/lib/libportmidi.dylib > PLIBS=$PLIBS -dynamiclib -Wl,-single_module -Wl,-install_name, > lportmidi > PLIBS=$PLIBS lportmidi > > (They compile fine but fail to load) > > libportmidi.dylib is installed in /usr/lib > and the environment variable > DYLD_LIBRARY_PATH is set to /usr/local/lib > > Recasting the plugin as a command line C application, > and dropping the relevant dylib into the XCode window > works with no bother. > > Cheers > Simon Last time I needed to do this I started with the XCode project for another plugin from SVN, modified it for my plugin, and just added the libs to it. Don't remember the details though. - Bert - |
Hmmm, thanks Bert! I'll have a root around. Another thouight was, seeing as its portmidi, there is an existing xcode project and an existing makefile either of which can assemble the library from scratch. But weaving the page-long library makefile into a mac intel plugin build appears an even knottier problem.... Simon |
In reply to this post by Bert Freudenberg
Aha - at first I couldnt see how an xcode project could merge with a VM configure/build but this starts to fill in the picture http://lists.squeakfoundation.org/pipermail/vm-dev/2005-November/000353.html Worth a try - I'll have a play Thanks, Bert! Simon |
In reply to this post by Bert Freudenberg
Thanks Bert! In case anyone should be looking for the answer at a later date, here is how to create an external squeak plugin on intel mac that links into an external library (e.g. a dylib or .a static library). 1/ Use xcode to make a carbon bundle project from scratch. 2/ Apart from your plugin code and your external library you will need to add the exactly correct minimum set of (slightly edited) vm header files. 3/ The set of headers and the necessary edit has been documented in Japanese by the Takashi Yamamiya http://www.smalltalk.jp/Squeak-ja/archives/lists.squeakfoundation.org/squeak-ja/2004-August/001783.html and written up in English by Gerald Leeb http://g-24.net/squeak/ode.html. 4/ If you then run a conventional unix vm/plugin macintel build for your plugin using a plugin Makefile.inc of PLIBS=$PLIBS -L/usr/local/lib -dynamiclib -Wl,-single_module -Wl,-install_name, lportmidi. (in my case, given that I was linking to portmidi and put the dylib in that location ) then the plugin will end up in the package contents of the VM. 4a/ Instead of step 4 you can just manually drop the plugin into the package contents of a VM of the right version number, which I assume is the normal deployment route. Thanks all! Simon |
Free forum by Nabble | Edit this page |