threaded-rts

[Wolfgang Thaller]

> Hi all,
>
> I've had a request for --enable-threaded-rts support in the Debian
> packages, but I don't want to just build with it as then HOpenGL can't
> be used.
>
> My hope was that I could share most files and just have a different
> binary or something for the threaded-rts

This is indeed the case. The threaded-rts switch only affects the 
runtime system, that is, libHSrts.a and libHSrts_p.a.
And of course, it affects all programs compiled by GHC; you should also 
ship two versions of the GHC binary itself, so that users can use ghci 
with or without the threaded rts.
Apart from that, you should be able to share everything else. (I think 
you can get away with just one version for the other utilities, they 
should behave the same in both cases.)

>  (it would be even better if a
> threaded-rts enabled binary could have it disabled by a +RTS flag, but 
> I
> don't think this is possible?).

Possible: probably, but replacing all the #ifdefs by runtime checks 
would be quite some work.

> However, various .hi, .a files and HSrts.o also seem to differ. So is
> the best way forward to create two completely separate packages?

HSrts.o contains the same code as libHSrts.a; however, I think it is 
never used; the other .o files are for GHCi, but AFAICT, GHCi never 
loads a second copy of the runtime system (nor should it). I think you 
can ignore this file, but if you want to be absolutely safe, make two 
versions of it or ask SimonM.

As for the .hi files... no idea why they should be different, the 
configure flag absolutely positively doesn't affect how the libraries 
are built - do the hi files perhaps contain a timestamp or something 
else that might change on its own?

In my development builds, I've successfully switched between threaded 
and non-threaded by just "make"ing and "make install"ing in the ghc/rts 
directory, and then re-linking the compiler.

Cheers,

Wolfgang