Dynamic Library Support for x86_64/Linux

[Simon Marlow]

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