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 <[email protected]> wrote: > On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila <[email protected]> > 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 > [email protected] > [email protected] > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- I drink I am thunk.
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
