Opened 6 years ago

Closed 18 months ago

#5289 closed bug (fixed)

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

Reported by: bos Owned by: Phyx-
Priority: normal Milestone: 8.0.1
Component: GHCi Version: 7.0.3
Keywords: Cc: pho@…, v.dijk.bas@…, vandijk.roel@…, ivan.stojic@…, howard_b_golden@…, echo@…, hartmut0407@…, rian@…, wren@…, leather@…, tim@…, hvr, idhameed@…, ryan.gl.scott@…
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1310
Wiki Page:

Description

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 :-(

Change History (60)

comment:1 Changed 6 years ago by 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.

comment:2 in reply to:  1 Changed 6 years ago by simonmar

Architecture: x86_64 (amd64)Unknown/Multiple
Milestone: 7.2.1
Operating System: LinuxUnknown/Multiple
Summary: Can't use ghci with a library linked against libstdc++ on LinuxCan't use ghci with a library linked against libstdc++

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.

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by 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.

comment:5 in reply to:  4 Changed 6 years ago by 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?

comment:6 Changed 6 years ago by 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.)

comment:7 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by PHO

Cc: pho@… added

comment:9 Changed 6 years ago by basvandijk

Cc: v.dijk.bas@… added

comment:10 Changed 6 years ago by Roel van Dijk

Cc: vandijk.roel@… added

comment:11 Changed 6 years ago by 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)

comment:12 Changed 6 years ago by bos

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

comment:13 Changed 6 years ago by ivanstojic

Cc: ivan.stojic@… added

comment:14 Changed 6 years ago by hgolden

Cc: howard_b_golden@… added

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).

comment:15 Changed 6 years ago by enolan

Cc: echo@… added

comment:16 in reply to:  11 ; Changed 6 years ago by 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.

comment:17 in reply to:  16 ; Changed 6 years ago by 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.

comment:18 Changed 6 years ago by Hartmut

Cc: hartmut0407@… added

comment:19 in reply to:  17 ; Changed 6 years ago by 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.

comment:20 in reply to:  19 ; Changed 6 years ago by 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.

comment:21 in reply to:  20 ; Changed 6 years ago by 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.

comment:22 in reply to:  21 Changed 6 years ago by 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.

comment:23 Changed 6 years ago by 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.

comment:24 Changed 6 years ago by 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.

comment:25 in reply to:  24 ; Changed 6 years ago by 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.)

comment:26 Changed 6 years ago by simonmar

Owner: set to simonmar
Priority: normalhigh

comment:27 Changed 6 years ago by 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(-)

comment:28 Changed 6 years ago by 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(-)

comment:29 in reply to:  25 Changed 6 years ago by simonmar

Resolution: fixed
Status: newclosed

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.

comment:30 Changed 6 years ago by bos

Wonderful, Simon - thanks!

comment:31 Changed 6 years ago by bos

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

comment:32 Changed 6 years ago by 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?

comment:33 Changed 6 years ago by simonmar

Milestone: 7.2.17.4.1
Owner: simonmar deleted
Priority: highnormal
Resolution: fixed
Status: closednew

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?

comment:34 Changed 6 years ago by 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?

comment:35 in reply to:  34 ; Changed 6 years ago by 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.

comment:36 Changed 6 years ago by 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.

comment:37 in reply to:  35 Changed 6 years ago by 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.

comment:38 Changed 5 years ago 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 :)

comment:39 Changed 5 years ago by rian

Cc: rian@… added

comment:40 Changed 5 years ago by igloo

Milestone: 7.4.17.6.1

comment:41 Changed 5 years ago by WrenThornton

Cc: wren@… added

comment:42 Changed 5 years ago by spl

Cc: leather@… added

comment:43 in reply to:  38 ; Changed 5 years ago by 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?

comment:44 in reply to:  43 Changed 5 years ago by 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.

comment:45 Changed 5 years ago by 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?

comment:46 Changed 5 years ago by igloo

Milestone: 7.6.17.6.2

comment:47 Changed 4 years ago by svenpanne

difficulty: Unknown

Asking 'gcc --print-file-name' might solve some of the C++ troubles mentioned above, but in general I feel that it is the wrong thing to do: GHCi is not mirroring what would happen at runtime for a compiled program, see e.g. https://github.com/haskell-opengl/OpenGL/issues/42 where the problem is described in length for libGL.so. In that special case it could be argued that the Ubuntu setup is a bit strange, but the C++ stuff above looks equally weird to me, too.

IMHO, if dlopen(foo, RTLD_LAZY) succeeds when looking for foo, one should not ask GCC and leave the path to foo as it is. GHCi will use the same mechanism later when loading/resolving symbols, anyway.

comment:48 Changed 4 years ago by MichalGajda

On Windows, this bug seems also to prevent linking libraries that depend on double-conversion and Template Haskell.

Last edited 4 years ago by MichalGajda (previous) (diff)

comment:49 Changed 3 years ago by blitzcode

Cc: tim@… hvr added

comment:50 Changed 3 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:51 in reply to:  48 Changed 3 years ago by MikolajKonarski

Replying to MichalGajda:

On Windows, this bug seems also to prevent linking libraries that depend on double-conversion and Template Haskell.

Are the symptoms similar to #9553? Does a similar workaround work?

comment:52 Changed 3 years ago by ihameed

Cc: idhameed@… added

comment:53 Changed 2 years ago by thomie

Operating System: Unknown/MultipleWindows

This is a Windows only bug now, if I understand correctly.

comment:54 Changed 2 years ago by RyanGlScott

Cc: ryan.gl.scott@… added

comment:55 Changed 2 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:56 Changed 19 months ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:57 Changed 18 months ago by Phyx-

Owner: set to Phyx-

comment:58 Changed 18 months ago by Phyx-

Differential Rev(s): Phab:D1310
Status: newpatch

comment:59 Changed 18 months ago by Thomas Miedema <thomasmiedema@…>

In 5d84110/ghc:

Add short library names support to Windows linker

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1310

GHC Trac Issues: #9878, #1407, #1883, #5289

comment:60 Changed 18 months ago by Phyx-

Resolution: fixed
Status: patchclosed
Note: See TracTickets for help on using tickets.