RFC: ghc's dynamic linker
Tue, 27 Aug 2002 08:46:12 -0700
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.
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.
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).
So, if the code can be executed by the O/S with ld.so, the symbol table is
I ran a quick test on these ideas and was able to run executables produced by
GHC on systems that have no part of GHC installed.
What am I missing here?
On Tuesday 27 August 2002 07:32, Alastair Reid wrote:
> Duncan Coutts <firstname.lastname@example.org> writes:
> > People want to write programs using Haskell as an extension
> > language. Think of a plugin system or an embeded language. This is
> > currently possible with ghc but requires some cunning hacks and
> > fiddling with the linker and it has some limiations.
> > [...]
> It seems like what you're asking for is partly covered by the
> foreign function interface specification
> especially foreign export (section 3.4), dynamic wrappers (section
> 4.1.3), and hs_init and friends (section 6.1).
> It'd be good if you could express your request in terms of things not
> provided by this interface, provided in an awkward or inappropriate
> way, etc. (bearing in mind that the ffi is often accessed indirectly
> through preprocessors like GreenCard, c2hs, hsc2hs, KDirect, HDirect,
> etc. which can eliminate much of the awkwardness).
M. I. S. Corp.