I've gleaned a little bit of useful info from looking at what GHC spits out with -v; I found that ordering the libraries in the way they do it makes one of my undefined symbols (`hs_free_stable_ptr') go away. However, my library ends up with a couple undefined __stginit_* symbols which prevent it from loading. I thought this might be a symptom of building Foo.o from Foo.hs with -dynamic; and indeed, building it without the -dynamic flag gives me an SO with many, many __stginit_* functions defined in it; but that SO causes the loader to segfault (both Ruby's DL/Import and my little test program). I'm trying to hew relatively close to Duncan Coutts' blog posting in working through this; so I have different code and a new Makefile: https://github.com/solidsnack/bash/tree/0e93b6aed7971886c12b95646e5baadc40fe... The three different permutations of SOs -- fully dynamic, fully static and hybrid -- each fail to load differently: :; ./loadfoo ./libfoo.dynamic-dynamic.so **** trying to load ./libfoo.dynamic-dynamic.so **** .so load error: /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so: undefined symbol: forkOS_createThread :; ./loadfoo ./libfoo.static-static.so **** trying to load ./libfoo.static-static.so Segmentation fault :; ./loadfoo ./libfoo.dynamic-static.so **** trying to load ./libfoo.dynamic-static.so **** .so load error: ./libfoo.dynamic-static.so: undefined symbol: __stginit_base_Prelude_dyn The little tester program, `loadfoo', is drawn from the blog post's example; Ruby's DL/Import fails the same way in each case. It would be pretty nice to demo an easy way to load and work with Haskell functions from Ye Olde Favorite Language. Seems like SOs "for the masses" will have to wait a little bit, though. -- Jason Dusek Linux User #510144 | http://counter.li.org/