Loading Shared Libraries

ardeujho ardeujho at cd.pn
Fri Mar 14 18:03:47 UTC 2014

In 'objects/applications/serverDemo' there is an example of loading a
shared library and using it from Self. The code has bitrot. The makefile
no longer works and the binaries in there are old. I've put a patch that
gets this working on Mac OS X at:


Also required is a fix to a core file:


Once that patch is applied you'll need to reload that file into your
image (or build a new one). That patch fixes an issue where Self
prepends an underscore to foreign function symbol names before lookup.

I haven't done a git pull request yet as I want to get this working on
Linux as well first but I'm traveling for a couple of days and won't get
around to that. I'm mentioning it here to get feedback before I add
other platform support.

To do the demo, after doing a Mac OS X build of Self, change to the
'objects/applications/serverDemo' directory and run 'make'. This will
build the shared library and C client program.

To run, start Self from the 'objects' directory:

$ cd objects
$ ../vm/Self.app/Contents/MacOS/Self -s myimage.snap

Then load the server.self file:

Self> bootstrap read: 'server' From: 'applications/serverDemo'.

Run the server:

Self> (message copy receiver: serverDemo server Selector: start) fork.

This will block as it runs a C 'accept' call exposed by the shared
library. In another terminal window run the client to send Self comands
to the server:

$ ./toself "'hello' print"
$ ./toself _Quit

Should this demo be kept the same? It uses the lower level Glue
functions directly? Or would it be better to modify it to use
primitiveMaker? Or maybe do a 'serverDemo2' that uses primitiveMaker to
compare the approaches?

Is there a better way to 'fork' the server? The example given in a
server.self comment uses a block but this fails due to non-LIFO blocks.

More information about the Self-interest mailing list