
On Sun, Jun 12, 2011 at 15:17, Jason Dagit
On Sun, Jun 12, 2011 at 11:45 AM, Brandon Allbery
wrote: On Sun, Jun 12, 2011 at 14:31, Jason Dagit
wrote: If I build the C library as a .a, then ghci comlains that it cannot open the .dylib. My first question is: Why does ghci need a .dylib and does it really use it?
Static libraries are... static. ghci would have to rebuild itself against the static archive to use it; that's how static archives work. Dynamic libraries are dynamic because they can be loaded at runtime instead of compile time.
Interesting. When I use dtruss to see what files ghci opens, it definitely opens .a files. That gave me the impression it knows how to open a .a and use it at run-time.
I would have to see a trace to be certain what's going on there, but what exactly does "static library" mean if static libraries are actually dynamic, and why then are there dynamic libraries if static libraries are actually dynamic?
It's hard for me to make sense of that ticket with so little context. This comment seems to go against what you're saying: Changed 10 months ago by igloo
milestone set to 6.16.1 The best way to achieve this is probably to switch to using dynamic libraries for GHCi.
The context for that remark is that GHC currently produces static libraries which contain references to system dynamic libraries when compiling a module; the plan is for ghc to produce dynamic libraries instead, which will simplify things considerably. (Come to think of it, this is probably why ghci is reading static libraries; they're the libHS*.a libraries and ghci is trying to find out what dynamic libraries it's supposed to load.) The translation of Igloo's comment is "we should just use the system linker the way it's supposed to be used instead of the current static+dynamic hack".