ghci and dynamically linking to Objective-C objects on Mac OS X
Hi all, I fear I might be unaware of something I should be. Say I have a file objc_util.m with the following contents: #include <Foundation/Foundation.h> void ns_log(const char *s) { NSString *str = [NSString stringWithUTF8String:s]; NSLog(@"%@", str); } I also have a file Main.hs with contents: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign.C.Types import Foreign.C.String foreign import ccall "ns_log" cNSLog :: CString -> IO () nsLog s = withCString s cNSLog I compile objc_util.m with: gcc -c objc_util.m And then I try to open it up in GHCi. ghci objc_util.o Main.hs -framework Foundation I add the flag '-frame Foundation' in the hopes that symbols in objc_util.o will get resolved dynamically. However I get: GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) objc_util.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/pv/pfxcyy117v31vt6lsshtgr_w0000gn/T/ghc33546_0/ghc33546_1.dylib, 9): Symbol not found: _OBJC_CLASS_$_NSString Referenced from: /var/folders/pv/pfxcyy1 17v31vt6lsshtgr_w0000gn/T/ghc33546_0/ghc33546_1.dylib Expected in: flat namespace in /var/folders/pv/pfxcyy117v31vt6lsshtgr_w0000gn/T/ghc33546_0/ghc33546_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug However, I have found a work around to this. If I do this: ln -s /System/Library/Frameworks/Foundation.framework/Foundation Foundation.o and then run ghci Foundation.o objc_util.o Main.hs I get this: GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) Foundation.o ... done Loading object (static) objc_util.o ... done final link ... done Everything has worked! And I can happily run 'nsLog' from GHCi and have it appear in the 'Console' app. However, it doesn't seem like I should have to do this. Where am I going wrong? Sean
On Sun, Mar 1, 2015 at 1:09 AM, Sean Seefried <sean.seefried@gmail.com> wrote:
However, it doesn't seem like I should have to do this. Where am I going wrong?
My guess is that the linker used by ghci (which is not the system linker, although there is ongoing work on that front) doesn't know how to deal with frameworks properly. You might have better luck turning your .o into a .dylib and linking *that* against the Foundation framework. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Sure, but shouldn't we perhaps just fix GHCi so that it does deal with frameworks properly? On 1 March 2015 at 18:25, Brandon Allbery <allbery.b@gmail.com> wrote:
On Sun, Mar 1, 2015 at 1:09 AM, Sean Seefried <sean.seefried@gmail.com> wrote:
However, it doesn't seem like I should have to do this. Where am I going wrong?
My guess is that the linker used by ghci (which is not the system linker, although there is ongoing work on that front) doesn't know how to deal with frameworks properly. You might have better luck turning your .o into a .dylib and linking *that* against the Foundation framework.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On Wed, Mar 4, 2015 at 4:34 PM, Sean Seefried <sean.seefried@gmail.com> wrote:
Sure, but shouldn't we perhaps just fix GHCi so that it does deal with frameworks properly?
Maintaining a completely separate linker instead of using the system's linker is a fool's errand that leads to things like this and inability to use ghci or TH on ARM, or having to have someone who does nothing but follow all the changes made to every system linker we care about and porting those changes to ghci's custom linker. The correct fix is the upcoming change to have ghci use the system linker. In the meantime, I offered a workaround. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Seems like pretty solid reasoning. I was unaware of this upcoming change. Can you tell me more about it? Which GHC release is it slated for? 7.12? On 5 March 2015 at 08:39, Brandon Allbery <allbery.b@gmail.com> wrote:
On Wed, Mar 4, 2015 at 4:34 PM, Sean Seefried <sean.seefried@gmail.com> wrote:
Sure, but shouldn't we perhaps just fix GHCi so that it does deal with frameworks properly?
Maintaining a completely separate linker instead of using the system's linker is a fool's errand that leads to things like this and inability to use ghci or TH on ARM, or having to have someone who does nothing but follow all the changes made to every system linker we care about and porting those changes to ghci's custom linker. The correct fix is the upcoming change to have ghci use the system linker. In the meantime, I offered a workaround.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On Wed, Mar 4, 2015 at 4:42 PM, Sean Seefried <sean.seefried@gmail.com> wrote:
Seems like pretty solid reasoning. I was unaware of this upcoming change. Can you tell me more about it? Which GHC release is it slated for? 7.12?
Well, it was originally scheduled for 7.8. :/ I don't see it in 7.10 offhand, so I presume it got bumped again. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
ghci in 7.8 uses the system linker. However, i suspect you'll find that linking to the objective c code works better when you COMPILE the haskell code first, then load in ghci the way to do this directly from GHCI is to invoke ghci with the -fobject-code flag. see https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci-obj.htm... that may very well resolve your problems (i'm juggling a few other things right now so I can't immediately verify my claims myself) On Wed, Mar 4, 2015 at 5:10 PM, Brandon Allbery <allbery.b@gmail.com> wrote:
On Wed, Mar 4, 2015 at 4:42 PM, Sean Seefried <sean.seefried@gmail.com> wrote:
Seems like pretty solid reasoning. I was unaware of this upcoming change. Can you tell me more about it? Which GHC release is it slated for? 7.12?
Well, it was originally scheduled for 7.8. :/ I don't see it in 7.10 offhand, so I presume it got bumped again.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (3)
-
Brandon Allbery -
Carter Schonwald -
Sean Seefried