8.4.3 installs but fails to run on MacOS High Sierra

[shaleh]

After installation I get this:

$ ghci
dyld: Library not loaded: /usr/local/lib/gcc/7/libgcc_s.1.dylib
  Referenced from: /Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3/bin/ghc
  Reason: image not found
Abort trap: 6

[gbaz]

Do you have developer tools installed from apple? those should provide your libgcc.

[shaleh]

1) Yes I do 2) No where does it say "install Xcode first", especially the command line tools.

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ llvm-gcc --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[gbaz]

Fair enough. It doesn't say that, and it probably should. But that said, I'm surprised that you can't then link against libgcc. The ghc we distribute is the one from upstream (the official ghc distro).

In that, I see, via otool -L /Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3/bin/ghc that it indeed lists a link against /usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0). However, I don't have that path present on my system, which is configured in the standard way, and things still work. In particular, it seems to pick up the lib from /usr/lib/libgcc_s.1.dylib. Is the latter not present on your system, or do you have any funny env vars set that affect library paths?

[gbaz]

Interestingly, my InstalledDir for gcc is InstalledDir: /Library/Developer/CommandLineTools/usr/bin while yours is inside the xcode app -- do you not have the commandline tools fully installed?

[gbaz]

Actually, for the record, the website doesn't say to install the command line tools, but the installer itself does (see screenshot below):

[shaleh]

Thank you. I missed that part. Ideally the installer would check and complain.

I have however used xcode and gcc. I can build emacs, Rust programs, etc. This is the first item I have failed to run.

$ ls -al /usr/local/lib/gcc/7/libgcc_s.1.dylib
ls: /usr/local/lib/gcc/7/libgcc_s.1.dylib: No such file or directory
$ ls -al /usr/lib/libgcc_s.1.dylib
lrwxr-xr-x  1 root  wheel  17 Mar 26 16:06 /usr/lib/libgcc_s.1.dylib -> libSystem.B.dylib
$ ls -al /usr/lib/libSystem.B.dylib
-rwxr-xr-x  1 root  wheel  65040 Jan 18 23:37 /usr/lib/libSystem.B.dylib
$ xcodebuild -version
Xcode 9.3.1
Build version 9E501

[gbaz]

Ok, do you have the command line tools installed, it is not clear to me if you do, or if you have something slightly different, given the difference in InstalledDir? Or is there anything else nonstandard in your installation? Otherwise, I confess that it isn't clear to me, unless, again, you have set a custom value for DYLD_FALLBACK_LIBRARY_PATH, DYLD_LIBRARY_PATH or any related env var?

[shaleh]

Yes, I was just coming to post that the issue is in fact a DYLD_FALLBACK_LIBRARY_PATH. I set one due to an issue with imagemagick. When I unset the variable ghci worked as expected. That was weird.

This makes my direct issue go away. But I suspect that it exposes a minor mistake in the compilation. ghci is clearly linked to /usr/local/ which I think means it was built using homebrew or the like gcc and not the standard.

Thank you @gbaz. I appreciate the help.

[gbaz]

Right. I'm going to close this as not a platform issue, but rather an issue with upstream ghc builds. However, I am also going to pass this on to the build manager for ghchq, so that they can be aware of it and maybe change things in the future. Thanks for the report!