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

[Simon Marlow]

On 14/06/2011 17:57, Jason Dagit wrote:
> On Tue, Jun 14, 2011 at 4:26 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>> On 12/06/2011 20:17, Jason Dagit wrote:
>>>
>>> On Sun, Jun 12, 2011 at 11:45 AM, Brandon Allbery<allbery.b at gmail.com>
>>>   wrote:
>>>>
>>>> On Sun, Jun 12, 2011 at 14:31, Jason Dagit<dagitj at 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