Re: RFC: ghc's dynamic linker

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 already present. 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? TIA, On Tuesday 27 August 2002 07:32, Alastair Reid wrote:

Duncan Coutts 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

http://www.cse.unsw.edu.au/~chak/haskell/ffi/

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).

-- ----------------------------------- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849