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 <edskodevries@gmail.com> wrote:
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 <edskodevries@gmail.com> 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