On 15/06/2011 15:41, Jason Dagit wrote:
On Wed, Jun 15, 2011 at 2:16 AM, Simon Marlow<marlo...@gmail.com> wrote:
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.
I can try this. I was hesitant to go down that road simply because
this dylib does work if I remove the memset and any code that writes
to that area of memory.
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.
Building GHC myself is no problem. I usually do that on OSX anyway so
that I can link with iconv from macports. This is the first time I've
used the Haskell Platform version of GHC on osx.
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?
I'm 99% sure those are from GDB. I don't see them unless I run ghci inside gdb.
Did you compile the source files with -fPIC? (I presume that's necessary,
but I don't know much about OS X).
I've tried with each -fPIC and -fno-common. The makefile I use is
linked in the original question, but here is the link again incase you
want to look at it:
https://github.com/dagit/GLFW-b/blob/master/Makefile
The current flag configuration matches what is in the git repo for
GLFW. When I tried with -fPIC I didn't notice any difference.
The symptoms don't look quite right, but I wonder if it is related to
this at all?
http://hackage.haskell.org/trac/ghc/ticket/781
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
