Nixpkgs: GHC on macOS fails with undefined symbols related to iconv.

[lrworth]

Issue description

On macOS 10.13.6, cabal-install (installed with a fresh Nix install) cannot build a new project due to not being able to find _iconv, _iconv_open, _iconv_close, and _locale_charset, all referenced by libHSbase.

Terminal output attached: log.txt

The build command executed by cabal is:

➜  ~/Test /Users/lukeworth/.nix-profile/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -odir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -hidir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -stubdir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -i -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -i. -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/global-autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/global-autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -I/Users/lukeworth/.nix-profile/include -optP-include -optP/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen/cabal_macros.h -L/Users/lukeworth/.nix-profile/lib -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/lukeworth/.cabal/store/ghc-8.4.3/package.db -package-db /Users/lukeworth/Test/dist-newstyle/packagedb/ghc-8.4.3 -package-db /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/package.conf.inplace -package-id base-4.11.1.0 -XHaskell2010 ./Main.hs -o /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test -hide-all-packages

If I append -liconv:

➜  ~/Test /Users/lukeworth/.nix-profile/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -odir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -hidir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -stubdir /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -i -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -i. -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen -i/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/global-autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/global-autogen -I/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test-tmp -I/Users/lukeworth/.nix-profile/include -optP-include -optP/Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/autogen/cabal_macros.h -L/Users/lukeworth/.nix-profile/lib -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/lukeworth/.cabal/store/ghc-8.4.3/package.db -package-db /Users/lukeworth/Test/dist-newstyle/packagedb/ghc-8.4.3 -package-db /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/package.conf.inplace -package-id base-4.11.1.0 -XHaskell2010 ./Main.hs -o /Users/lukeworth/Test/dist-newstyle/build/x86_64-osx/ghc-8.4.3/Test-0.1.0.0/x/Test/build/Test/Test -hide-all-packages -liconv

the build succeeds and the generated program executes as expected.

I have just freshly installed Nix 2.1.1 and cabal-install/ghc was one of the first things I installed.

Steps to reproduce

nix-env -i ghc
nix-env -i cabal-install
mkdir Test
cd Test
cabal init
# Accept all default options
cabal new-build

Technical details

• system: "x86_64-darwin"
• host os: Darwin 17.7.0, macOS 10.13.6
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.1.1
• channels(root): "nixpkgs-19.03pre152754.f456d7f5753"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixpkgs

[matthewbauer]

Yep this is definitely new. Pretty serious though. Looks like it effects both unstable and 18.09.

[matthewbauer]

18.03 does not have this issue. You can install from it with:

nix-env -f channel:nixos-18.03 -iA ghc

[lrworth]

Thanks, that works for me.

[LnL7]

Is this only a problem with new-build or does the old style build also fail?

[lrworth]

Is this only a problem with new-build or does the old style build also fail?

build also fails with the same message.

[Ericson2314]

@dtzWill I recall at some point some native-only --with-* flags were removed related to libaries? I think those caused various paths to be hard-coded in GHC.

[jhenahan]

Is there a known workaround for this other than pulling GHC from another channel?

[lrworth]

I'm now using macOS 10.14 and nixpkgs-unstable, and can no longer reproduce this problem.

[TomMD]

That is odd to hear, lrworth. I just got a new macbook today with 10.14, installed nixpkgs using nixpkgs-unstable as the channel (odd to me that this is default, coming from a debian background) and your above issue is exactly what I ran into when building https://github.com/matterhorn-chat/matterhorn

In short: I discourage closing the issue just yet.

[matthewbauer]

Hi all!

I believe I have found the issue here. We add the -liconv flag as a setup hook since 9e75fb5eb4f26de4e551137c3caaa78b9bf8b050. This is so that packages that don't explicitly add the liconv flag will work on macOS like they do on GNU Linux. But this breaks when GHC checks for libiconv with this check here:

https://github.com/ghc/packages-base/blob/master/configure.ac#L191

and our -liconv hack means that -liconv doesn't get into LDFLAGS. This is because it tries to compile a simple program & it works:

https://github.com/tpetricek/Haskell.Extensions.Base/blob/master/aclocal.m4#L214

But only in the builder! Once you have the unwrapped builder, things will break. This is why it will work in a nix-shell / nix-build but not outside of it. Anyway, I'm recompiling now, but should be able to get a PR soon & backport it to 18.09.

[matthewbauer]

Fixed in #51455.

[nmattia]

I'm hitting this in 18.09 (50f41ea2fcf86def32799f75577a4fe5cfd1132e).

[...], I [...] should be able to [...] backport it to 18.09.

@matthewbauer was it backported to 18.09?

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _hs_iconv in libHSbase-4.11.1.0.a(iconv.o)
     (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding1_info, _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure )
  "_iconv_open", referenced from:
      _hs_iconv_open in libHSbase-4.11.1.0.a(iconv.o)
     (maybe you meant: _hs_iconv_open)
  "_iconv_close", referenced from:
      _hs_iconv_close in libHSbase-4.11.1.0.a(iconv.o)
     (maybe you meant: _hs_iconv_close)
  "_locale_charset", referenced from:
      _localeEncoding in libHSbase-4.11.1.0.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64

[matthewbauer]

Thanks for reminding me! I usually like to wait to make sure these things don't cause catastrophic issues. But this has been in master for a little bit so we can definitely cherry pick.

I put it in 88157a2a4898d5d6ed811dbedd9cb53dabd98c40 in staging-18.09. It should be merged into release-18.09 in a few weeks. For now, you should be able to get it directly from unstable:

$ nix-env -iA ghc -f channel:nixpkgs-unstable

(for ghc 863)

[nmattia]

Thanks! I'll patch my nixpkgs for now.

[arkrost]

Same issue for ghc 8.6.3.