GHCI doesn't work with dtrace on OS X

[rl]

On OS X, user-defined dtrace probes are implemented as special symbols of the form ___dtrace_probe$... which are magically resolved by the linker. In the attached package, we have this dtrace script:

provider haskell {
  probe demo__trace(char*);
};

and this C file:

void demo_trace( char *s )
{
  HASKELL_DEMO_TRACE(s);
}

When we compile it, we get:

newbie:dtrace-demo rl$ nm demo-trace.o
         U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
         U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
         U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace

When linked as a dynamic library, the undefined symbols disappear:

newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o 
newbie:dtrace-demo rl$ nm demo-trace.dylib 
00000000 t __mh_dylib_header
000008b0 T _demo_trace

But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, ghci -package dtrace-demo produces this error:

unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'

Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.

The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.

[duncan]

dlopen() cannot load .o files, only .so / .dynlib files. As I understand it that's the reason for the ghci linker in the first place. The system linker is already used for the cases it can cope with.

Moving to building Haskell packages as shared libs would solve this problem for packages but not for .o files in the local build tree.