Dynamic linking again
Simon Marlow
simonmar@microsoft.com
Mon, 2 Sep 2002 15:16:37 +0100
> In fact it all works quite nicely, I've got a test program
> with a little
> plugin module that refers back to the main program. When the main
> program is linked with -optl-export-dynamic the plugin can be
> loaded up
> and all symbols resolve correctly. I still had to load copies of the
> base packages since the plugin .o still refers to symbols not in the
> main executalbe. (More on that in a moment)
>
> And yes indeed, it works with a vanilla ghc-5.04
Great stuff! I've just linked a copy of GHCi that doesn't need to load
up the base package when it starts :-) However, the binary is ~15Mb
compared to ~8Mb normally.
> > To like the whole of the base package into the binary, you
> can either
> > use --whole-archive with libHSbase.a as suggested by
> Alastair, or link
> > in HSbase.o. Similarly for the haskell98 package.
>
> I got lots of linking errors about duplicate symbols doing using
> --whole-archive for the standard packages. Perhaps someone who knows a
> bit more about linking could advise me.
I couldn't get it to work either - although I didn't get any duplicate
symbols when linking, it seems the resulting binary didn't have all the
symbol information from the library in it. It looks like
-export-dynamic doesn't work properly with --whole-archive.
> ghc -optl-export-dynamic -ldl -L/usr/lib/ghc-5.04/ -lHSrts
> -lHSlang \
> TestDLink.o -o TestDLink
>
> since doing
>
> ghc -optl-export-dynamic -ldl -package rst -package lang \
> TestDLink.o -o TestDLink
>
> gives:
> /usr/lib/ghc-5.04/libHSrts.a(RtsAPIDeprec.o): In function
> `rts_mkAddr':
> RtsAPIDeprec.o(.text+0x14): undefined reference to `Addr_Azh_con_info'
> /usr/lib/ghc-5.04/libHSrts.a(RtsAPIDeprec.o): In function
> `rts_getAddr':
> RtsAPIDeprec.o(.text+0x2d): undefined reference to `Addr_Azh_con_info'
> RtsAPIDeprec.o(.text+0x35): undefined reference to
> `Addr_Azh_static_info'
> collect2: ld returned 1 exit status
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.
> So generally quite sucessful. I should probably come up with some
> tutorial / documentation on doing plugins with ghc.
That's a good plan. We can probably make it easier too, perhaps by
providing a flag to do the right magic at link-time. I need to think
about this some more.
Cheers,
Simon