linker error on OSX (symbol not found "_iconv")

ld: couldn't dlopen() /usr/lib/libdtrace.dylib:
Hi, On OSX Yosemite I am facing the following build failure while building from the master (please find the complete error at the bottom of the email): 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
Can someone kindly point me what am doing wrong? FWIW, with the same configuration options, source distribution of ghc-7.8.4 from https://www.haskell.org/ghc/download_ghc_7_8_4 goes through successfully. I am using gcc (MacPorts gcc49 4.9.2_1) 4.9.2 Thanks, Hemanth The complete error message: ===--- building phase 0 /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Library/Developer/CommandLineTools/usr/bin/make -r --no-print-directory -f ghc.mk phase=final all "rm" -f rts/dist/build/libHSrts-ghc7.11.20150103.dylib "inplace/bin/ghc-stage1" -this-package-key rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,@loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/StaticPtrTable.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/AutoApply.dyn_o -optl-m64 -fPIC -dynamic -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -fno-use-rpaths -o rts/dist/build/libHSrts-ghc7.11.20150103.dylib 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 make[1]: *** [rts/dist/build/libHSrts-ghc7.11.20150103.dylib] Error 1 make: *** [all] Error 2

On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila
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

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
On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila
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.

On Sun, Jan 4, 2015 at 11:06 AM, Hemanth Kapila
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.
So presumably ghc HEAD requires a newer iconv now, presumably for better encoding handling. Many things do, which is why both MacPorts and Homebrew include the newer one (and then must hack around incompatibility) instead of sticking to Apple's. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery
-
Hemanth Kapila