If anyone is curious, I've posted a possible solution at the stack overflow post:
http://stackoverflow.com/questions/6323755/osx-ghci-dylib-what-is-the-correct-way/6439016#6439016 I'd appreciate any feedback (and/or refutations), especially regarding the commentary re: ghci and loading static archives. Excerpts from Simon Marlow's message of Wed Jun 15 16:55:05 +0200 2011: > 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
