Can't use ghci with a library linked against libstdc++

[bos]

My double-conversion library links to a C++ library. If I build it and try to use it from ghci, I get a failure:

Prelude Data.Double.Conversion.Text Data.Text> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> 
Leaving GHCi.
~ $ ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)

I can sort of work around this, but then I get a different crash:

~ $ ln -s /usr/lib64/libstdc++.so.6 libstdc++.so
~ $ LD_LIBRARY_PATH=$(pwd) ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... linking ... done.
"Floating point exception (core dumped)

Unfortunately, gdb doesn't give me a useful stack trace from this :-(

[bos]

Actually, I see a similar shared library loading error with ghci on OS X:

Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (dlopen(libstdc++.dylib, 9): image not found)

Actually, this shared library problem seems to be the same problem as reported in #3789.

[simonmar]

Replying to bos:

Actually, I see a similar shared library loading error with ghci on OS X: {{{ Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (dlopen(libstdc++.dylib, 9): image not found) }}} Actually, this shared library problem seems to be the same problem as reported in #3789.

I think you meant #3798, right?

That ticket is a bit confusing, I'm going to close it in favour of this one, and copy the comment I made on #3798 to here:

On my system, libstdc++.so is found in /usr/lib/gcc/i486-linux-gnu/4.4.1, but it is a symlink to to .so.6 in /usr/lib. If you add that directory to the extra-libs of the wxcore package, it loads in GHCi (although there's another missing symbol error later). dlopen doesn't look here by default, as this directory is intended to be searched at link-time, not load-time. If you want to dlopen libstdc++, I guess you're supposed to either dlopen("libstdc++.so.6") or use the full path name.

One possible plan here is to have GHCi call gcc -print-search-dirs, and pick out its library search paths. We could easily add those to the places we look for .sos.

[bos]

Sorry, yes, #3798 it was.

It seems that this bug affects not just ghci, but also code that uses Template Haskell (and perhaps other GHC API users?).

See the following thread for details:  http://www.haskell.org/pipermail/web-devel/2011/001929.html

[bos]

I think that the proposed solution of using gcc -print-search-dirs may not necessarily be correct. For instance, under Linux, libstdc++.so is a symlink to the real libstdc++.so.6, and on many distros the symlink won't be present if the libstdc++-devel package or its equivalent has not been installed.

I believe the real problem is that ghc records the plain name of the library that is depended upon at build time, when instead it should be either following the symlink or interpreting the ld script, and storing the complete path to that, just like the normal system linker does.

[simonmar]

Replying to bos:

I believe the real problem is that ghc records the plain name of the library that is depended upon at build time, when instead it should be either following the symlink or interpreting the ld script, and storing the complete path to that, just like the normal system linker does.

Hmm, I'm not sure I follow. When we build a package we don't normally do a link step, we just record the library dependencies in the package. I guess you're suggesting that we should resolve the libraries at that point, and that sounds reasonable, but how would we find them without using gcc -print-search-dirs?

[bos]

You're right that you'll have to find the real file somehow.

It should be easiest to use gcc -print-file-name, as it emits far less gunk.

On my Mac:

$ gcc -print-file-name=libstdc++.dylib
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib

Under Linux:

$ gcc -print-file-name=libc.so
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../libc.so

(Alas, as the libc.so example shows, it doesn't interpret the linker script.)

[ArnoVanLumig]

It seems that libraries using hint to interpret code suffer from the same problem, because my snap project which uses double-conversions only works when not running in development mode due to this error.

[bos]

On Mac OS X, if I strong-arm ghci into finding libstdc++, it fails:

$ ln -sf $(gcc -print-file-name=libstdc++.dylib)
$ ls -l libstdc++.dylib 
lrwxrwxr-x  1 bos  staff  54 Jul 15 12:31 libstdc++.dylib@ -> /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib
$ ghci
GHCi, version 7.0.3: http://www.haskell.org/ghc/  :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 1
Loading [...]
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (dlopen(libstdc++.dylib, 9): no suitable image found.  Did find:
	libstdc++.dylib: can't map)

[bos]

Oh, and the same error occurs on OS X if I set DYLD_LIBRARY_PATH instead of using a symlink.

[hgolden]

I'm unfamiliar with OS X, but I tried this under Linux with GHCi 7.0.4. Here's what I get:

$ ghci
GHCi, version 7.0.4: 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 ffi-1.0 ... linking ... done.
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 1
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.1 ... linking ... done.
Loading package double-conversion-0.2.0.0 ... linking ... done.
"Floating point exception (core dumped)

Possibly this error comes from ticket #3333 (which I should work on!).

The "can't load..." on OS X possibly can be fixed by code similar to what I put in ticket #2615, since it looks like the linker scripts on OS X are similar. In fact, I was thinking of proposing a patch to dlopen upstream so all languages can benefit from this (but that's another story).

[bos]

Following up with myself:

On Mac OS X, if I strong-arm ghci into finding libstdc++, it fails [...]

I can no longer reproduce that problem, so I don't know what was causing it.

Now, I get the same floating point exception as reported by hgolden on both Linux and OS X.

So the crux of this bug remains that ghc/ghci needs to record the path to a shared library, because even if the file could originally be linked against when the program was being built, it's not guaranteed to be on the *runtime linker*'s search path.

[hgolden]

Replying to bos:

So the crux of this bug remains that ghc/ghci needs to record the path to a shared library, because even if the file could originally be linked against when the program was being built, it's not guaranteed to be on the *runtime linker*'s search path.

At least on Linux, I agree with simonmar. I tried the following command and got the results below:

$ ghci -lstdc++
GHCi, version 7.0.4: 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 ffi-1.0 ... linking ... done.
Loading object (dynamic) stdc++ ... done
final link ... done
Prelude> 

To me, this means that ghci dynamic loader can find libstdc++. Note: On my system, it is located at /usr/lib/libstdc++.so.5 which is a symlink to /usr/lib/libstdc++.so.5.0.7.

bos: Does the floating point exception only occur when using ghci, but not ghc? If it occurs in both, is it possible that there is a bug in double-conversion or the underlying library? Before trying to find and fix a problem in ghc/ghci, I want to be sure the problem really is in ghc/ghci.

[bos]

Replying to hgolden:

To me, this means that ghci dynamic loader can find libstdc++. Note: On my system, it is located at /usr/lib/libstdc++.so.5 which is a symlink to /usr/lib/libstdc++.so.5.0.7.

That's not what ghci is finding. If you run it under strace, you'll find that it is picking up a symlink named libstdc++.so somewhere else. ghci doesn't search for a shared library by its extended name, only with the .so suffix.

bos: Does the floating point exception only occur when using ghci, but not ghc?

Right. But that's not my focus here. I might open a separate bug for that. This one should remain focused on the library finding issue.

[hgolden]

Replying to bos:

Replying to hgolden:

To me, this means that ghci dynamic loader can find libstdc++. Note: On my system, it is located at /usr/lib/libstdc++.so.5 which is a symlink to /usr/lib/libstdc++.so.5.0.7.

That's not what ghci is finding. If you run it under strace, you'll find that it is picking up a symlink named libstdc++.so somewhere else. ghci doesn't search for a shared library by its extended name, only with the .so suffix.

I was incorrect before about the location of the shared library. Here is the correct explanation:

dlopen looks in /lib/ld.so.cache for "libstdc++.so" (which is what ghci asks for when it gets the option "-lstdc++"). It finds the first entry that corresponds to the particular system in use (for me, libc6,x86-64). On my system this entry is /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so. On my system, that is a symlink to /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6.0.14.

In other words, libstdc++.so is NOT a symlink. It is an entry in /lib/ld.so.cache.

You can see all the /lib/ld.so.cache entries your system has by using the command "ldconfig -p".

Right. But that's not my focus here. I might open a separate bug for that. This one should remain focused on the library finding issue.

I still believe that libstdc++ is being found using dlopen. I suspect that the reason the initial report couldn't find libstdc++.so was that the entry in /lib/ld.so.cache (or its OS X equivalent) was missing. Perhaps later you rebuilt /lib/ld.so.cache which may explain why you aren't able to reproduce the original error.

[ivanstojic]

Replying to hgolden:

Replying to bos:

That's not what ghci is finding. If you run it under strace, you'll find that it is picking up a symlink named libstdc++.so somewhere else. ghci doesn't search for a shared library by its extended name, only with the .so suffix.

I was incorrect before about the location of the shared library. Here is the correct explanation: dlopen looks in /lib/ld.so.cache for "libstdc++.so" (which is what ghci asks for when it gets the option "-lstdc++"). It finds the first entry that corresponds to the particular system in use (for me, libc6,x86-64). On my system this entry is /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so. On my system, that is a symlink to /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6.0.14. In other words, libstdc++.so is NOT a symlink. It is an entry in /lib/ld.so.cache. You can see all the /lib/ld.so.cache entries your system has by using the command "ldconfig -p".

That is indeed so on Linux, but OS X is a vastly different beast.

From the man pages:

Unlike many other operating systems, Darwin does not locate dependent dynamic libraries via their leaf file name. Instead the full path to each dylib is used (e.g. /usr/lib/lib-System.B.dylib).

I'm not sure how that affects the specified behavior though. To me it always looked as if GHCi cannot even locate the library to work with in the first place.

[hgolden]

Replying to ivanstojic:

From the man pages: Unlike many other operating systems, Darwin does not locate dependent dynamic libraries via their leaf file name. Instead the full path to each dylib is used (e.g. /usr/lib/lib-System.B.dylib). I'm not sure how that affects the specified behavior though. To me it always looked as if GHCi cannot even locate the library to work with in the first place.

I hope someone with Mac OS X programming skills would look at rts/Linker.c, particularly the dynamic loading code, and see if it works. I don't have programming experience with Mac OS X, and my only easy access is to an old PPC Mac anyway, so I don't think I can help much.

[simonmar]

Just to clarify: GHCi searches the library paths from the package to find shared libs, and if it doesn't find the library there, then it tries calling dlopen without an explicit path, so that dlopen will search the standard system locations (the cache is a red herring, it just caches the contents of the system paths). libstdc++ is unusual in that the .so link is not in one of the standard system paths, it is somewhere like /usr/lib/gcc/x86_64-linux-gnu/4.4.3, which is known only to gcc and not to ld.so, hence it cannot be found by dlopen.

The easiest fix is to add a backup plan to GHCi's search strategy, namely to invoke gcc --print-file-name=libfoo.so.

[simonmar]

bos: I'm looking at this and I'm not sure I agree with your original suggestion, that we should record the full path name to the versioned .so because the user may not have installed the appropriate -devel package.

If the user has not installed the appropriate -devel package, then they cannot link anything with GHC, so it seems reasonable that they would also not be able to link anything with GHCi either. I don't think of GHCi as doing "runtime linking", it's just doing ordinary linking, but storing the result in memory for immediate execution instead of on disk.

So unless anyone persuades me otherwise, I'm going to implement the simple fix I described above, which is to use gcc --print-file-name as another strategy for mapping library names to file names in GHCi.

[bos]

Replying to simonmar:

bos: I'm looking at this and I'm not sure I agree with your original suggestion, that we should record the full path name to the versioned .so because the user may not have installed the appropriate -devel package.

I was coming to this with the perspective that ghci is effectively doing runtime linking. If you don't agree, that's fine :-)

The main consequence of the distinction that I can see is that a #!/usr/bin/runghc script will not work under your view of things unless a -devel package is installed. I've never seen such a script in the wild except for Setup.lhs, so that doesn't seem like a big deal to me.

So unless anyone persuades me otherwise, I'm going to implement the simple fix I described above, which is to use gcc --print-file-name as another strategy for mapping library names to file names in GHCi.

Cool! Will that same fallback work for both runghc and Template Haskell? Certainly TH is affected by this bug, so I assume that all users of the GHC API would be. (Actually, that makes me wonder about some of the web-development packages that use dynamic reloading.)

[marlowsd@…]

commit d146fdbbf8941a8344f0ec300e79dbeabc08d1ea

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Wed Aug 3 09:39:48 2011 +0100

    Followup to #5289 changes: fix searching for dynamic libraries and use
    of the RTS addDLL() API on Windows.  When searching for DLLs we should
    include the .dll extension, but addDLL() takes a filename without the
    extension.

 compiler/ghci/Linker.lhs  |    4 +---
 compiler/ghci/ObjLink.lhs |   19 +++++++++++++++++--
 2 files changed, 18 insertions(+), 5 deletions(-)

[marlowsd@…]

commit 9babbc8ddb62308762947debfe022635df1fce82

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Tue Aug 2 14:17:18 2011 +0100

    Fix #5289 (loading libstdc++.so in GHCi), and also fix some other
    linking scenarios.  We weren't searching for .a archives to satisfy
    -lfoo options on the GHCi command line, for example.
    
    I've tidied up the code in this module so that dealing with -l options
    on the command line is consistent with the handling of extra-libraries
    for packages.
    
    While I was here I moved some stuff out of Linker.hs that didn't seem
    to belong here: dataConInfoPtrToName (now in new module DebuggerUtils)
    and lessUnsafeCoerce (now in DynamicLoading, next to its only use)

 compiler/ghc.cabal.in             |    2 +-
 compiler/ghci/DebuggerUtils.hs    |  129 +++++++++++++++++++++
 compiler/ghci/Linker.lhs          |  228 ++++++++++---------------------------
 compiler/ghci/RtClosureInspect.hs |    1 +
 compiler/main/DynamicLoading.hs   |   21 ++++-
 compiler/main/SysTools.lhs        |   84 ++++++++++----
 6 files changed, 268 insertions(+), 197 deletions(-)

[simonmar]

Replying to bos:

The main consequence of the distinction that I can see is that a #!/usr/bin/runghc script will not work under your view of things unless a -devel package is installed. I've never seen such a script in the wild except for Setup.lhs, so that doesn't seem like a big deal to me.

This is true, however if that becomes a problem then GHC should be made to depend on the -devel versions of the system libraries it depends on.

Cool! Will that same fallback work for both runghc and Template Haskell? Certainly TH is affected by this bug, so I assume that all users of the GHC API would be. (Actually, that makes me wonder about some of the web-development packages that use dynamic reloading.)

Yes: GHCi, runghc and TH all use the same linking mechanisms inside GHC.

This does *not* work on Windows currently. Here's the current situation; see #4468 for background.

You can force the stdc++ DLL to be loaded in GHCi by asking for it explicitly, and adding mingw/bin from your GHC installation to the PATH, so that the other DLLs it depends on can be found:

PATH=c:/ghc/ghc-7.2.1/mingw/bin:$PATH
ghci c:/ghc/ghc-7.2.1/mingw/bin/libstdc++-6.dll

Note the DLL is called libstdc++-6.dll, so it won't be found by the normal search strategy.

We have a static libstdc++.a, but it probably isn't a good idea to load this into GHCi because GHC's linker won't run the constructors. I'm guessing that would be a problem for C++ code, but I haven't tried it.

[bos]

Wonderful, Simon - thanks!

[bos]

As a final note, the floating point exception crash is now documented in ticket #5386.

[hvr]

btw, this ticket is currently set as resolved for milestone:7.2.1, i.e. it shows up as fixed in 7.2.1, is this really accurate?

[simonmar]

It's fixed on Linux, but not Windows or Mac OS X, so I'll re-open the ticket for those two platforms. I'm not hopeful that we can fix it on Windows (see comment:29). Any Mac experts want to look into this for OS X?

[basvandijk]

I guess the fix has not found its way in ghc-7.2.1 because I get the same error:

$ ghci -package double-conversion
GHCi, version 7.2.1: 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.2.0 ... linking ... done.
Loading package array-0.3.0.3 ... linking ... done.
Loading package containers-0.4.1.0 ... linking ... done.
Loading package deepseq-1.1.0.2 ... linking ... done.
Loading package text-0.11.1.5 ... linking ... done.
Loading package double-conversion-0.2.0.1 ... <command line>: 
can't load .so/.DLL for: libstdc++.so 
(libstdc++.so: cannot open shared object file: No such file or directory)

This also happens when building packages with ghc that depend on double-conversion.

I hope there will be a bugfix release that fixes this because I'm currently unable to build some packages. Or is there a quick work-around?

[hvr]

Replying to basvandijk:

I hope there will be a bugfix release that fixes this because I'm currently unable to build some packages. Or is there a quick work-around?

If you are on a Ubuntu-like distribution and don't mind exposing libstdc++.so you can link, you could symlink it to /usr/local/lib, e.g.

$ ln -vs $(gcc --print-file-name=libstdc++.so) /usr/local/lib/
`/usr/local/lib/libstdc++.so' -> `/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libstdc++.so'

This works for me currently.

It might also work (though I haven't tried whether GHC picks up on it) to put the symlink in some user-owner directory, e.g. ${HOME}/lib and point LD_LIBRARY_PATH to it.

[simonmar]

Sorry folks, due to an oversight on my part I forgot to ask Ian to merge the fix into the 7.2 branch. It'll be in 7.4.1.

[basvandijk]

Replying to hvr:

If you are on a Ubuntu-like distribution and don't mind exposing libstdc++.so you can link, you could symlink it to /usr/local/lib, e.g.

Thanks hvr!

Note to others: I needed to do a sudo ldconfig after this to update my cache.

[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 :)

[spl]

rian's workaround worked for me on OS X 10.5 (GHC version 7.4.1.20120508):

sudo ln -s /usr/lib/libstdc++.6.0.4.dylib /usr/lib/libstdc++.dylib

Just curious: what's the current status on this issue?

[hgolden]

Replying to spl:

Just curious: what's the current status on this issue?

It seems unchanged since Simon's comment above. We need to know if there is some facility in OS X to convert a reference to /usr/lib/libstdc++.dylib to the specific version in use on that machine. (I know how to do that in Linux, but I have no experience with OS X.) Until then, the workaround symbolic link is available. However, it shouldn't be expected of the average programmer.

[spl]

I'm not that familiar with the machinery of dynamic linking or building OS-X-specific apps, but it appears to me that you might be able to simply change the name of the library you're looking for under OS X.

If I understand it correctly, the path to libstdc++ is found with gcc --print-file-name now:

$ gcc --print-file-name=libstdc++.dylib
/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib

This seems to explain the error for loading double-conversion:

$ ghci -package double-conversion
GHCi, version 7.4.1.20120508: 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.2.1 ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package text-0.11.2.1 ... linking ... done.
Loading package double-conversion-0.2.0.4 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib (dlopen(/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib, 9): no suitable image found.  Did find:
	/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib: can't map)

But if I want the libstdc++ that seems to work, I look for libstdc++.6.dylib:

$ gcc --print-file-name=libstdc++.6.dylib
/usr/lib/libstdc++.6.dylib

So, does it make sense to use libstdc++.6.dylib instead of libstdc++.dylib on OS X?