On February 22, 2010 17:00:25 Max Bolingbroke wrote:

Hi Tyson,

This blog post (/) 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).

Thanks Max. Those were good write ups. I'm pleased to report that I've got GHC hooked into Perl as a shared library (i.e., can call my GHC code from Perl). I'm working on trying to get a reasonable build system solution now. So far I've been trying to build a single shared library, but I thinking the easiest/intended way might be to just get GHC to just build its own library and then specify it as a required shared library to the Perl stub library. This way I wouldn't have to mix flags from the build systems in the final link. (although a shared library of stubs to a shared library seems a bit strange) Cheers! -Tyson PS: Thanks to everyone responsible for getting shared libraries working.

The usual way to do this would be to include the dependency on the RTS in the library and then vary the RTS by using LD_PRELOAD. I think ghc does it the wrong way. -- Lennart On Mon, Feb 22, 2010 at 10:00 PM, Max Bolingbroke wrote:

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 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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users