#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
