Re: [Haskell-cafe] OSX, ghci, dylib, what is the correct way?

On Wed, Jun 15, 2011 at 2:16 AM, Simon Marlow wrote:

On 14/06/2011 17:57, Jason Dagit wrote:

...

On Tue, Jun 14, 2011 at 4:26 AM, Simon Marlow  wrote:

...

On 12/06/2011 20:17, Jason Dagit wrote:

...

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.

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. Thanks, Jason