Dynamic linking again

[Andre Pang]

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 <ozone@algorithm.com.au>          - trust.in.love.to.save