
Ok, I finally figured out what was going on. At the time that I installed
gcc-4.9 (through brew) I did not have the Xcode command line tools
installed. As a result, gcc was using the linker from the SDK; gcc-4.9 -v
reported:
Configured with: ../configure --build=x86_64-apple-darwin13.3.0
--prefix=/Users/dev/brew/Cellar/gcc49/4.9.0
--enable-languages=c,c++,objc,obj-c++ --program-suffix=-4.9
--with-gmp=/Users/dev/brew/opt/gmp4 --with-mpfr=/Users/dev/brew/opt/mpfr2
--with-mpc=/Users/dev/brew/opt/libmpc08
--with-cloog=/Users/dev/brew/opt/cloog018
--with-isl=/Users/dev/brew/opt/isl011 --with-system-zlib
--enable-version-specific-runtime-libs --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --with-pkgversion='Homebrew gcc49 4.9.0' --with-bugurl=
https://github.com/Homebrew/homebrew-versions/issues --enable-plugin
--disable-nls --enable-multilib
--with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
Note the sysroot. I think this ultimately causing ghc to load the wrong
dynamic library (from /Applications/.. rather than /usr/lib). Once I
rebuilt gcc _after_ installing the command line tools (xcode-select
--install) gcc reports:
Configured with: ../configure --build=x86_64-apple-darwin13.3.0
--prefix=/Users/dev/brew/Cellar/gcc49/4.9.0
--enable-languages=c,c++,objc,obj-c++ --program-suffix=-4.9
--with-gmp=/Users/dev/brew/opt/gmp4 --with-mpfr=/Users/dev/brew/opt/mpfr2
--with-mpc=/Users/dev/brew/opt/libmpc08
--with-cloog=/Users/dev/brew/opt/cloog018
--with-isl=/Users/dev/brew/opt/isl011 --with-system-zlib
--enable-version-specific-runtime-libs --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --with-pkgversion='Homebrew gcc49 4.9.0' --with-bugurl=
https://github.com/Homebrew/homebrew-versions/issues --enable-plugin
--disable-nls --enable-multilib
and now when I install ghc (with gcc-4.9 as the C compiler) ghci and TH
work. Finally :)
Edsko
On Fri, Jul 18, 2014 at 4:48 PM, Edsko de Vries
No, it's ghc-7.4.2-x86_64-apple-darwin.tar.bz2 from haskell.org/ghc.
Turns out it's got nothing to do with vector per se. ghci doesn't work either (should have realized this sooner -- it's going wrong when TH initializes when building vector).
-E
On Fri, Jul 18, 2014 at 4:36 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
Is this a 32bit ghc? It's complaining about libiconv beig the wrong architecture.
On Friday, July 18, 2014, Edsko de Vries
wrote: Hi guys,
I am currently unable to build vector on OSX:
Loading package base ... <command line>: can't load .so/.DLL for: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib, 9): no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib: mach-o, but wrong filetype) cabal: Error: some packages failed to install: vector-0.10.11.0 failed during the building phase. The exception was:
This has been reported before as some kind of clang issue, but I am using gcc 4.8 (ghc-7.4.2/settings has "gcc-4.8" for "C compiler command").
Any suggestions?
Thanks!
Edsko