On Wed, Sep 04, 2002 at 11:28:24 +0100, Simon Marlow wrote:
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.
It seems to be linked into Duncan's TestDynLink program: 20:55 ~/projects/haskell_dynamic_linking/dynlink % nm -A TestDynLink-nostrip | grep Addr | grep Addr_Azh_con_info TestDynLink-nostrip:084ea8dc T Addr_Azh_con_info 20:56 ~/projects/haskell_dynamic_linking/dynlink % HSlang.o appears to contain the symbol (and therefore libHSlang.a does), and it's required by other files which go into libHSlang.a (ByteArray, PackedString) and also libHSrts.a. I'm not sure what to conclude from that, but it does end up in the final program.
... -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.
No, the line which works is definitely the second line -- Duncan manually added the /usr/lib/ghc-5.04/HSbase.o file to his Makefile since he didn't want to have to explicitly load up the base library when his program started.
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.
Yep, Duncan manually added it to the command line ... see above.
--
#ozone/algorithm