
I'm not sure exactly what's going here. RtsAPIDeprec.o 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.
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):
... -L/usr/lib/ghc-5.04 -L/usr/lib/gcc-lib/i386-linux/3.2 -L/usr/lib/gcc-lib/i386-linux/3.2/../../.. Main.o -ldl -lHSlang -lHSlang_cbits -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i386-linux/3.2/crtend.o /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o ... -L/usr/lib/ghc-5.04/ -L/usr/lib/ghc-5.04 -L/usr/lib/gcc-lib/i386-linux/3.2 -L/usr/lib/gcc-lib/i386-linux/3.2/../../.. /usr/lib/ghc-5.04/HSbase.o Main.o -ldl -lHSrts -lHSlang -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i386-linux/3.2/crtend.o /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o
.. so the only real difference between the line which works and the line which doesn't work is:
* 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. 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