Hi Tyson,
This blog post (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/)
might help explain the motivation (actually there are a few relevant
posts on the well-typed site).
Essentially, I believe that this is done so that you can vary the RTS
by changing LD_LIBRARY_PATH. I've never used this facility so I'm
unable to say how useful this actually is (or if it actually works at
the moment).
Cheers,
Max
On 22 February 2010 21:34, Tyson Whitehead
I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols.
A bit of digging and it seems that GHC doesn't embed
- the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1
into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols.
I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though?
Thanks! -Tyson
PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing
- the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them)
$ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ...
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users