Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iconv linker error #825

Closed
alexbiehl opened this issue Aug 20, 2015 · 24 comments
Closed

iconv linker error #825

alexbiehl opened this issue Aug 20, 2015 · 24 comments

Comments

@alexbiehl
Copy link
Contributor

@alexbiehl alexbiehl commented Aug 20, 2015

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
Copy link
Contributor

@borsboom borsboom commented Aug 21, 2015

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

@carrutstick
Copy link

@carrutstick carrutstick commented Aug 25, 2015

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
Copy link
Contributor

@borsboom borsboom commented Aug 28, 2015

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

@carrutstick
Copy link

@carrutstick carrutstick commented Aug 28, 2015

@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
Copy link

@budgefeeney budgefeeney commented Aug 28, 2015

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
Copy link
Contributor

@borsboom borsboom commented Sep 5, 2015

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?

@snoyberg snoyberg added this to the Support milestone Sep 6, 2015
@alexbiehl
Copy link
Contributor Author

@alexbiehl alexbiehl commented Sep 10, 2015

Yes, we could solve it by adding

extra-lib-dir: 
  - /usr/lib

to our stack.yaml.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Sep 10, 2015

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
Copy link

@drewr drewr commented Sep 14, 2015

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
Copy link

@drewr drewr commented Sep 15, 2015

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
Copy link
Contributor

@erikkaplun erikkaplun commented Dec 7, 2015

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
Copy link

@erewok erewok commented Apr 16, 2016

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
Copy link

@LucianU LucianU commented Mar 7, 2018

I tried the solution proposed and put

extra-lib-dirs:
    - /usr/lib

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

@slyfr
Copy link

@slyfr slyfr commented Mar 7, 2018

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
Copy link

@cmal cmal commented Nov 20, 2018

It does not work for nix based package management.

@leemhenson
Copy link

@leemhenson leemhenson commented Dec 9, 2018

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
Copy link

@leemhenson leemhenson commented Dec 11, 2018

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
Copy link

@mouse07410 mouse07410 commented Jan 14, 2019

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
Copy link

@jjant jjant commented Mar 24, 2019

Any solution to this?

@mouse07410
Copy link

@mouse07410 mouse07410 commented Mar 24, 2019

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
Copy link

@dmitriz dmitriz commented Aug 18, 2019

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

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

@mouse07410
Copy link

@mouse07410 mouse07410 commented Aug 18, 2019

@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
Copy link

@dmitriz dmitriz commented Aug 19, 2019

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
Copy link

@mouse07410 mouse07410 commented Aug 19, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests