Dynamic linking again

[Simon Marlow]

> > I'm not sure exactly what's going here.  RtsAPIDeprec.o=20
> does refer to
> > Addr_Azh_con_info, which is defined in the Addr module in the lang
> > package.  However, RtsAPIDeprec normally isn't linked in, because
> > nothing refers to anything in it.
>=20
> RtsAPIDeprec.o is in libHSrts.a (as the error message says).
> Therefore using libHSrts.a means that you'll get all of
> RtsAPIDeprec.o along with it, and therefore need to resolve all
> its unresolved symbols.

er, no.  An object file from a library is only linked in if one of the
symbols it exports is required by the main program.  So RtsAPIDeprec.o
normally isn't linked in.

> I think I also understand why using -package doesn't work.  I'll
> paste in two (cropped) gcc lines below; the first line is when
> you use the "-lHSrts -lHSlang" options (which works), and the
> second is when you use "-package rts -package -lang" (which
> doesn't work):
>=20
>     ... -L/usr/lib/ghc-5.04                     =20
> -L/usr/lib/gcc-lib/i386-linux/3.2=20
> -L/usr/lib/gcc-lib/i386-linux/3.2/../../..                   =20
>         Main.o -ldl          -lHSlang -lHSlang_cbits=20
> -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp -lm -lgcc=20
> -lgcc_eh -lc -lgcc -lgcc_eh=20
> /usr/lib/gcc-lib/i386-linux/3.2/crtend.o=20
> /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o
>     ... -L/usr/lib/ghc-5.04/ -L/usr/lib/ghc-5.04=20
> -L/usr/lib/gcc-lib/i386-linux/3.2=20
> -L/usr/lib/gcc-lib/i386-linux/3.2/../../..=20
> /usr/lib/ghc-5.04/HSbase.o Main.o -ldl -lHSrts  -lHSlang     =20
>           -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp=20
> -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh=20
> /usr/lib/gcc-lib/i386-linux/3.2/crtend.o=20
> /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o
>=20
> .. so the only real difference between the line which works and
> the line which doesn't work is:
>=20
>     * line which works has /usr/lib/ghc-5.04/HSbase.o
>     * line which works has an extra -lHSrts flag

Now I'm really confused.  Maybe you got these round the wrong way:  the
"line which works" is the first line according to the first paragraph
above, but it doesn't contain /usr/lib/ghc-5.04/HSbase.o, which is in
the second line.

And where on earth did /usr/lib/ghc-5.04/HSbase.o come from anyway?
That must have been specified on the command line too.

To link in the whole base package and enable -export-dynamic this works
(for me):

	ghc Foo.o Bar.o .... /path/to/HSbase.o -optl-Wl,export-dynamic

> It turns out that the pedant linker needs to see the -lHSrts flag
> before -lHSlang.  This is a bit odd, since the HSlang library is
> the one which has the required "Addr_Azh_con_info" symbol.

The RTS has several forward references of this kind.  To ensure that
this works, we add a number of '-u' options to the linker command line
(see the package spec for the 'rts' package).  We *don't* do this for
the forward references from RtsAPIDeprec, because that would force us to
link the lang package every time. =20

RtsAPIDeprec should really go away.  In order to use it at all you'd
have to go through some contortions to get the linking to work, so I
don't imagine anyone is using it.

Instead of using the -u options we could use the --start-group and
--end-group options of GNU ld, but this is likely to be (a) less
portable and (b) slower.

Cheers,
	Simon