#4464: RTS options broken for dynamic libraries
---------------------------------+------------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.1 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
There are several problems here. Firstly, GHC doesn't seem to respect
`-rtsopts` when linking dynamic libraries. In !DriverPipeline,
`linkDynLib` doesn't care about the flag, only `linkBinary` does. This
causes `hs_init` to fail if called with some RTS options. This is a
blocker for us.
Secondly, here is a snipped from `hs_init` in !RtsStartup.c:
{{{
setFullProgArgv(*argc,*argv);
setupRtsFlags(argc, *argv, &rts_argc, rts_argv);
setProgArgv(*argc,*argv);
}}}
Of these, `setFullProgArgv` copies the things pointed to by `argc` and
`argv` (good), `setProgArgv` doesn't copy (bad) and `setupRtsFlags`
doesn't seem to, either (it calls `setProgName` which doesn't copy, at
least). We probably should have `setupRtsFlags` and `setProgArgv` create
its own copy of the args as well and document that the caller doesn't have
to hang on to the memory after the call. Alternatively, the docs should
make it ''very'' clear that the memory must remain allocated until the RTS
is shut down.
Finally, `hs_init` simply aborts if it doesn't like the RTS arguments
which is quite unhelpful for dynamic libraries. I took me a day to find
out that an application crash was caused by a failing `hs_init` (because
of the `-rtsopts` problem). I would like to add a check for this to our
code but there doesn't seem to be a way to do this. It would be much nicer
if `hs_init` returned a failure/success code, at least for dynamic
libraries.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4464>
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
