id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
4464,RTS options broken for dynamic libraries,rl,,"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.",bug,closed,normal,7.2.1,Runtime System,7.1,fixed,,,Unknown/Multiple,Unknown/Multiple,None/Unknown,,,,,