#5289: Can't use ghci with a library linked against libstdc++ -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: GHCi crash | -------------------------+--------------------------------------------------
Comment(by rian): hi all ran into this problem on my 10.6 Mac (i will test out 10.7 tomorrow). my ghci & ghc build steps were failing with: {{{ $ ghci -package double-conversion GHCi, version 7.0.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 package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.1.9 ... linking ... done. Loading package double-conversion-0.2.0.1 ... <command line>: can't load .so/.DLL for: stdc++ (dlopen(libstdc++.dylib, 9): image not found) }}} don't know anything about the ghc stack / internals or how double- precision is implemented but it looked to me like this was calling dlopen("libstdc++.dylib", RTLD_LAZY | RTLD_GLOBAL) at runtime (i'm guessing via the native FFI). normally i would dig in and start up dtrace but it's 5am here atm. (btw i do know the internals of dyld) i did a quick ls in /usr/lib: {{{ $ ls -l /usr/lib/libstdc++* -rw-r--r-- 1 root wheel 15400372 Jun 24 2010 /usr/lib/libstdc++-static.a -rwxr-xr-x 1 root wheel 2435792 Dec 8 2010 /usr/lib/libstdc++.6.0.9.dylib lrwxr-xr-x 1 root wheel 21 Dec 8 2010 /usr/lib/libstdc++.6.dylib -> libstdc++.6.0.9.dylib }}} another quick pattern patch: {{{ $ ls -l /usr/lib/libbz2* lrwxr-xr-x 1 root wheel 16 Dec 8 2010 /usr/lib/libbz2.1.0.5.dylib -> libbz2.1.0.dylib -rwxr-xr-x 1 root wheel 216704 Dec 15 2010 /usr/lib/libbz2.1.0.dylib lrwxr-xr-x 1 root wheel 16 Dec 8 2010 /usr/lib/libbz2.dylib -> libbz2.1.0.dylib }}} it looked to me like there was no base libstdc++.dylib, just the versioned file. '''so i did a quick symlink in /usr/lib''': {{{ $ sudo ln -s /usr/lib/libstdc++.6.0.9.dylib /usr/lib/libstdc++.dylib }}} fired up ghci: {{{ $ ghci -package double-conversion GHCi, version 7.0.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 package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.1.9 ... linking ... done. Loading package double-conversion-0.2.0.1 ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> }}} yay!! as to why there was no base libstd++.dylib, well i'm guessing it isn't common to use dlopen() to load libstd++.dylib and it's probably wrong to do that. libstd++ should be implicitly linked by ld. does ghc save dynamic dependencies at build time and later manually attempt to explicitly load all dynamic links via dlopen()? or is the FFI library (as invoked by double-conversion) doing this? these are questions i could problem answer myself were it not 5.30am now :) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5289#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs