On Tue, Jul 22, 2003 at 08:11:03PM +0200, Wolfgang Thaller wrote: > > > >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.)
That, along with your HSrts.o later, ties in with the files that change file size except that /usr/lib/ghc-6.0/package.conf gains a "pthread" in the rts extra libraries. It looks like I want to make a package-threaded.conf that thinks the rts package is 'hs_libraries = ["HSrts-threaded"],' which I install into the same directory and then change ghc/compiler/main/SysTools.lhs to use this name in initSysTools when making the threaded rts version. Oh, and I probably want another ghc-pkg that knows about package-threaded.conf too. > > (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. I meant possible at the moment - just checking I hadn't missed something. > >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? Could be - looking at one of the .a files at random (libHSposix.a) it looks like it is the timestamps of the files inside it that has changed. FWIW the .hi differences on /usr/lib/ghc-6.0/imports/GHC/Int.hi are: (again chosen at random) (note that these are not contiguous) -00006fb0 00 14 bc 84 08 00 01 00 00 00 0c 00 00 00 04 1c |..�.............| +00006fb0 00 10 bb 84 08 00 01 00 00 00 0c 00 00 00 04 1c |..�.............| -00007130 00 14 bc 84 08 00 01 00 00 00 0c 00 00 00 04 1c |..�.............| +00007130 00 10 bb 84 08 00 01 00 00 00 0c 00 00 00 04 1c |..�.............| -00013ae0 03 01 00 00 00 01 00 00 00 08 02 00 00 00 10 a4 |...............�| -00013af0 1c 41 00 01 00 00 00 01 00 00 00 00 00 00 75 00 |.A............u.| +00013ae0 03 01 00 00 00 01 00 00 00 08 02 00 00 00 50 1e |..............P.| +00013af0 7c 08 00 01 00 00 00 01 00 00 00 00 00 00 75 00 ||.............u.| -00013b30 00 00 e0 a4 2b 40 00 01 00 00 00 01 00 00 00 00 |[EMAIL PROTECTED]| +00013b30 00 00 50 1e 7c 08 00 01 00 00 00 01 00 00 00 00 |..P.|...........| but they are the same when I --show-iface both of them. I think I'll assume the differences aren't important unless a problem shows up, anyway. > 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. OK, thanks. One more thing - is there an easy way to check to see if it has worked? I assume a Haskell program can't tell whether or not it is being run in a threaded-rts? I have access to a dual-CPU machine so I can time things with and without if that makes sense. Thanks Ian _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
