On 14/06/2011 17:57, Jason Dagit wrote:
On Tue, Jun 14, 2011 at 4:26 AM, Simon Marlow<marlo...@gmail.com> wrote:
On 12/06/2011 20:17, Jason Dagit wrote:
On Sun, Jun 12, 2011 at 11:45 AM, Brandon Allbery<allber...@gmail.com>
wrote:
On Sun, Jun 12, 2011 at 14:31, Jason Dagit<dag...@gmail.com> 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.
GHC as of version 7.0 can load .a files into GHCi.
When I build a dylib I get a [segfault when loading the code into
ghci][2].
I don't know what the cause of that is - when you load a .dylib into GHCi,
the normal system dynamic linker is used.
How would you track it down? I'd really like to fix this and I don't
mind debugging it, but I've tried all the things I could think of
(valgrind, dtruss, gdb and printf). Valgrind didn't help because ghci
couldn't read from stdin. gdb isn't so great because I was missing
debug symbols for everything.
I don't really believe it is an error in the RTS or the library code
so it seems like gdb won't ever help here.
Ideas?
Can you build a simple .dylib, load it into GHCi and call it from
Haskell? If that works, then see if you can gradually evolve the tiny
example towards the real failure case and see at which point it fails.
Can you build GHC yourself? If so, you can link GHC with -debug, and
that will give you access to the debugging output from the linker (+RTS
-Dl) and gdb will have source information about the RTS.
I don't know who is generating those messages about "Reading symbols for
shared libraries ...", or the ones about "Could not find object file",
maybe those are generated by the system linker?
Did you compile the source files with -fPIC? (I presume that's
necessary, but I don't know much about OS X).
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
