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 <[email protected]> wrote: > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
