Clemens Fruhwirth wrote:
Hi everyone,
I'm happy to announce that dynamic library support is back and shows
promissing results with the testsuite. At the beginning of the year we
had a similar situation but then due to my lack of time, I was not
able to complete the whole thing and it started bitrotting. But in the
last two weeks I got most build errors fixed.
The situation at the moment is
"./configure --enable-shared" gives you stage2 compiler that makes use
of the ghc package in form of a shared lib. So it replaces the static
compiler. With previous incarnations of the build system we had the
possibility to build a "ghc" binary which was the static compiler, and
a "ghc_dyn" binary which was the same compiler but linked to a shared
lib. But now the situation is different, and either "ghc" is produced
shared or not.
This makes it difficult to integrate into the regular testsuite, as
you can't test shared AND static, you can only test shared OR
static. We can either:
But this is only how GHC itself is linked, right? You can still compile
individual tests both static and dynamically linked using either -dynamic
or -static.
1. add a new build bot that specifically tests shared libs, that means
calls ./configure --enable-shared.
That seems sensible. We could add it to one of the existing HEAD builds.
It would build both shared and static libraries, and test both.
Do installation and binary distributions work yet? The issue with these is
that we want the shared libraries to be installed in $libdir, not
$libdir/ghc-6.11.
2. hack support for also producing "_dyn" binary into Cabal (probably
also "_p_dyn" that is shared libs + profiling mode). Then add "dyn"
test way (iirc the testsuite should still be able to do that,
without much trouble). I personally think that's the easiest.
3. (brave) turn on --enable-shared by default on certain archs. To
form an opinion about this option one should probably have a look
at the set of regressions we have at the moment
http://hackage.haskell.org/trac/ghc/ticket/1876 . What's
interesting about them is that most of the ghci suite works, but
only in some isolated cases we see failures. We probably need
someone with RTS-fu to have a look at that, as my gdb debugging
session ended without any insights into the problem.
I'll try to get to that at some point (busy working on parallel stuff at
the moment).
The trouble with making --enable-shared the default is that it entails
building each library twice, which will slow down validate. I'd like it to
be possible to build *just* shared libraries, that is ./configure
--enable-shared --disable-static.
Also we need to clear up the situation with mixing shared/static libraries
in an executable (what happens and on which platforms?) and whether Cabal
defaults to producing shared and/or static libraries.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
