Hi,

Thanks for the reply. I understand that discrepancy between macports and system libraries are causing this issue but I am not using the environment variable DYLD_LIBRARY_PATH.

More over, I can build ghc-7.8.4 from sources, with the same configuration options. I repeated it there.

I thought it is likely that I should see the same issue there as well.

I am not able to figure out the exact dependency issue here - apparently, libHSrts cannot be built with the system version of libiconv (configure step fails), while at the same time "ghc-stage1" relies on some system tool that needs older version of libiconv.

Is that a fair picture of the problem? I wondered why this does not occur for ghc-7.8.4 distributed sources.

I thought something got inadvertently modified in the compiler/main folder since the release of 7.8.4 and resulted in this issue. That's why I posted it over here. However, by the looks of it, it is just me..

Thanks again,

Hemanth

On Sun, Jan 4, 2015 at 7:45 PM, Brandon Allbery <allbery.b@gmail.com> wrote:

On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila <saihemanth@gmail.com> wrote:
> ld: couldn't dlopen() /usr/lib/libdtrace.dylib: dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv
> Referenced from: /usr/lib/libmecabra.dylib
> Expected in: /opt/local/lib/libiconv.2.dylib
> in /usr/lib/libmecabra.dylib for architecture x86_64
> collect2: error: ld returned 1 exit status

You are mixing Apple and MacPorts libraries. (The same will happen with Homebrew but it'll be using /usr/local/lib/libiconv.2.dylib.) Possibly you also have DYLIB_LIBRARY_PATH set, which will compound the problem; *please* do not do this. You are not on Linux where setting LD_LIBRARY_PATH is common and relatively safe, DYLIB_LIBRARY_PATH will break things.

The iconv libraries contain static data which is not compatible between versions, leading to core dumps unless something is done to force a link time error. Both MacPorts and Homebrew rename symbols in iconv to force this error.

Since you are building ghc, either you have forced it to use MacPorts libraries when it otherwise wouldn't (see above re DYLD_LIBRARY_PATH) or you at some point copied MacPorts libraries into system library paths (OS X bakes full paths into object files and dylibs. This also means such libraries cannot be used on a system without MacPorts installed without at minimum using install_name_tool to change the baked-in paths).

--
brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

I drink I am thunk.