#3807: Test for correct shared library generation
---------------------------------+------------------------------------------
Reporter: asuffield | Owner: duncan
Type: bug | Status: new
Priority: high | Milestone: 6.14.1
Component: Test Suite | Version: 6.12.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by duncan):
It is right that we currently do not automatically link shared libs to the
rts. This is because we have not got round to sorting that out yet.
Currently people making shared libs to be dlopen()ed have to add the link
to a specific flavour of the rts themselves. The plan is to have a scheme
where we link to the rts but do not commit to which flavour, so that one
can override the choice later either during a final link of an executable,
or e.g. at runtime with LD_PRELOAD. This is so that the same lib can be
used with the normal, threaded or profiling versions of the runtime.
For a test then, at the moment it would have to add a -l link flag for the
rts, e.g. the normal rts way. The dlopen test is a good idea. It just
needs the extra step at the moment of manually adding a link flag for the
rts.
See: http://www.well-typed.com/blog/30
I thought we also had a ticket about the rts linking issue but I cannot
find it. If we don't, we should. The idea is to have all the rts ways use
the sane SONAME but to live in different directories. Then we link things
to the rts soname and give an rpath to one rts flavour, but the top level
binary can use its own rpath, also any LD_PRELOADed rts will take
precedence.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3807#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
