[Haskell-cafe] OSX, ghci, dylib, what is the correct way?
dagitj at gmail.com
Wed Jun 15 16:41:55 CEST 2011
On Wed, Jun 15, 2011 at 2:16 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 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>
>>>>> 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
>>> I don't know what the cause of that is - when you load a .dylib into
>>> 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.
> 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:
The current flag configuration matches what is in the git repo for
GLFW. When I tried with -fPIC I didn't notice any difference.
More information about the Haskell-Cafe