RFC: ghc's dynamic linker

[Duncan Coutts]

On Tue, 27 Aug 2002 08:46:12 -0700
Seth Kurtzberg <seth@cql.com> wrote:

> I don't understand something about this discussion which is probably just 
> ignorance on my part, so apologies in advance.  Or, perhaps what I'm thinking 
> doesn't apply in all environments.

Sorry, it is rather confusing. X linking with Y linkng with itself! Eugh. :-)

> Watching what happens when ghc compiles a module (this doesn't apply to ghci, 
> just to compilation), the executable is actually created by a call to gcc.  
> Gcc is already capable of linking statically, creating a program that can run 
> without the presence of ghc on a machine.

Yes.

> Furthermore, when a (normally, that is, dynamically) linked executable 
> (created by ghc) is executed, the dynamic loader is not anything specific to 
> ghc but is just the normal O/S dynamic loader (typically ld.so).

There's two different kinds of dynamic linking when it come to ghc! ghc
produces executibles that are statically linked with the Haskell
libraries but dynamically linked with certian C libraries ie libc and gmp.

ghci has its own dynamic linker for linking pre-compiled .o modules or
packages with each other and with byte code.

> So, if the code can be executed by the O/S with ld.so, the symbol table is 
> already present.

Yes / maybe. As the Haskell object code is staticaly linked, there is no
need to keep the symbol table around, so if you strip (the final
executable) they will disapear. .so files obviously have to keep their
symbols so that they can be linked at runtime, I guess they use some
special ELF section for that.

> What am I missing here?

Does this make any sense? :-)

Duncan