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/
e
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Shared GHC libraries and the runtime system
|
| 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
| >
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
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_LIBRAR
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 li