iconv linker error

[alexbiehl]

Hello,

just ran stack setup and stack build (using lts-3.0, ghc-7.10.2) on a otherwise ghc free OSX enviroment and got:

  "_iconv", referenced from:

      _hs_iconv in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)

     (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info, _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info )

  "_iconv_close", referenced from:

      _hs_iconv_close in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)

     (maybe you meant: _hs_iconv_close)

  "_iconv_open", referenced from:

      _hs_iconv_open in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)

     (maybe you meant: _hs_iconv_open)

  "_locale_charset", referenced from:

      _localeEncoding in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(PrelIOUtils.o)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Manually installing libiconv doesn't change anything.

[borsboom]

Is there any chance that you have multiple versions of libiconv installed? This looks similar to haskell/haskell-platform#74.

[carrutstick]

I have this issue, and I do have multiple versions of libiconv installed. The question for me is, how do I get stack to link ghc against the version I want to use? This seems like it could be a big issue for mac-users, as many of our c-libraries (and thus many haskell packages) rely on alternatives to the system-installed libraries.

[borsboom]

@carrutstick: I use OS X but haven't run into this yet. Is there an approach you use with cabal?

[carrutstick]

@borsboom, I think it's that I have the latest version of iconv installed through macports (in /opt/local/lib), but there is also a system version (slightly out of date) that lives in /usr/lib. After a fresh stack setup, running otool -L on the ghc binary shows me that it is linked to /usr/lib/libiconv.2.dylib. I think this is what causes problems later, as many c library dependencies need to be linked against the version of iconv in /opt/local/lib. Is there a way to get stack to link ghc against the macports version instead? Or do you think I'm barking up the wrong tree as far as this issue goes?

[budgefeeney]

I've experienced the exact same problem, trying to install IHaskell. I installed stack and then used it to install GHC. I then installed the required zeromq library using MacPorts, and then tried to install IHaskell using stack install ihaskell and got the iconv error below.

GHC is linked to iconv in /usr/lib, zeromq is obviously linked to iconv in /opt/local/lib

As @carrutstick mentioned, typically on Macs,the latest versions of libraries are installed in either /usr/local/lib (Homebrew) or in /opt/local/lib (MacPorts). Developers need to be able to specify the library path, as there is no simple, straightforward way of installing libraries into /usr/lib

[24 of 24] Compiling IHaskell.Publish ( src/IHaskell/Publish.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/IHaskell/Publish.o )
    In-place registering ihaskell-0.6.5.0...
    Preprocessing executable 'ihaskell' for ihaskell-0.6.5.0...
    [1 of 2] Compiling IHaskellPrelude  ( main/IHaskellPrelude.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/ihaskell/ihaskell-tmp/IHaskellPrelude.o )
    [2 of 2] Compiling Main             ( main/Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/ihaskell/ihaskell-tmp/Main.o )
    Linking .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/ihaskell/ihaskell ...
    Undefined symbols for architecture x86_64:
      "_iconv", referenced from:
          _hs_iconv in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)
         (maybe you meant: _hs_iconv, _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure )
      "_iconv_close", referenced from:
          _hs_iconv_close in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)
         (maybe you meant: _hs_iconv_close)
      "_iconv_open", referenced from:
          _hs_iconv_open in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(iconv.o)
         (maybe you meant: _hs_iconv_open)
      "_locale_charset", referenced from:
          _localeEncoding in libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(PrelIOUtils.o)
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

[borsboom]

FWIW, I was able to stack install ihaskell using the Homebrew version of zeromq (brew install zeromq) on Yosemite, without any linking errors. So a workaround for now might be to use Homebrew instead of MacPorts.

I think to move forward on fixing the underlying issue, we need to know how this would be addressed using arguments to ghc and/or cabal configure. Once we know that, we can decide how best to have stack provide appropriate arguments. I did a bit of searching and found some rather old articles, of which this one seemed the most helpful. Does this advice still apply?

Are any of those of you experiencing this problem able to put some effort into researching a solution?

[alexbiehl]

Yes, we could solve it by adding

extra-lib-dir: 
  - /usr/lib

to our stack.yaml.

[borsboom]

Ok, sounds like that's the right solution. You could put that in your ~/.stack/stack.yaml if you want it to be the a default for all projects.

[drewr]

This doesn't work for me trying to install alex-3.1.4. I have MacPorts and OEM libiconv. Looks like I'll be building stack on my own unless someone has one they can give me! 😍

[drewr]

FYI, I ended up working around it by building libssh2 (the original thing I had MacPorts in the chain for) in /usr/local. Then I could remove /opt/local from the build and no more conflicts.

[erikkaplun]

I believe that should be:

extra-lib-dirs: 
  - /usr/lib

— note the plural.

however, is it possible to only enable it for a single dependency, not all of them?

[erewok]

For what it's worth, I had this problem on El Capitan and I had libiconv installed in the usual place, /usr/lib as well as one installed by Postgresql in that that application's libraries. I finally just installed another one with homebrew (brew install homebrew/dupes/libiconv) and added the following the stack.yaml for the project that was suffering under this issue (I figured the ordering was important):

extra-lib-dirs:
  - /usr/local/opt/libiconv/lib
  - /usr/local/lib
  - /usr/lib

[LucianU]

I tried the solution proposed and put

extra-lib-dirs:
    - /usr/lib

in ~/.stack/config.yaml, but I still get the error.

[slyfr]

I have the same problem and cannot get out of it... It occurs when doing stack setup. I use macport gcc, macport clang and I have put the lib dirs and include dirs to be macport ones as follows in the ~/.stack/config.yaml

extra-lib-dirs:

• /opt/local/lib

extra-include-dirs:

• /opt/local/include

[cmal]

It does not work for nix based package management.

[leemhenson]

Same issue here. MacOS Mojave clean install, stack 1.9.3. Running stack setup 8.6.2 --verbose gives

Linking /private/var/folders/zc/j9bt51b92v36tms2_8r7sh600000gn/T/stack-sanity-check28624/Main ...
Standard error:

ld: library not found for -liconv
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

I tried brew install libiconv and stack setup 8.6.2 --verbose --extra-lib-dirs=/usr/local/opt/libiconv/lib --extra-include-dirs=/usr/local/opt/libiconv/include but that made no difference. I also tried all the different combinations of flags mentioned for ~/.stack/config.yaml.

I'd be interested to know if anyone has been able to run stack setup on a newly-installed modern macos?

[leemhenson]

A follow up for time travellers from the future, I was able to resolve this issue by reverting from the version of gcc provided by nixpkgs to the version of gcc bundled with Mojave.

[mouse07410]

Same issue here. Neither forcing gcc to /usr/bin/gcc, nor putting extra-lib-dirs: seem to help. MacOS Mojave 10.14.2, current Macports, current Haskell Platform (GHC-8.6.3).

Must add that cabal works correctly, and coexists with Macports, using the approach outlined above. It accepts ghc-options: -optL=/usr/lib/libiconv.dylib (format a bit different, but you got the idea), and allows to specify the exact compiler binary.

[jjant]

Any solution to this?

[mouse07410]

For most packages, the above (or similar - adding cabal option "ghc-options: /usr/lib/libiconv.dylib") helps. Usually I employ "v1-..." commands and force system-ghc.

"stack" behaves much worse, but quite a few packages build ok with this option too (and system-ghc, in whatever way you can tell stack to do it). But some - like "ghc-paths" or "intero" - fail to build under "stack" no matter what. Basically, I gave up on "stack" as hopeless.

[dmitriz]

I have experienced the same issue and was able to fix it by running

$ stack build --ghc-options "-L/usr/lib"
$ stack install

[mouse07410]

@dmitriz are you saying that it worked for you for all packages???

In my case it worked for most, but not all. Particularly, problems with big and flakey ones like "intero".

[dmitriz]

I have only tried two packages recently, ptghci and iHaskell, both had the issue that was gone after I put that option.

I have not tried "intero" yet, is it showing exactly the same error that wouldn't go away with that option?

[mouse07410]

So, in general your experience seems to match mine: for the majority of packages this option helps. But for some it didn't help.

I haven't tried intero myself for quite a while. What about ghc-paths package?