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

GHC on macOS fails with undefined symbols related to iconv. #46814

Closed
lrworth opened this issue Sep 18, 2018 · 15 comments
Closed

GHC on macOS fails with undefined symbols related to iconv. #46814

lrworth opened this issue Sep 18, 2018 · 15 comments
Assignees
Labels
0.kind: regression Something that worked before working no longer 1.severity: blocker This is preventing another PR or issue from being completed 6.topic: darwin Running or building packages on Darwin 6.topic: haskell 9.needs: port to stable A PR needs a backport to the stable release.
Milestone

Comments

@lrworth
Copy link
Contributor

lrworth commented Sep 18, 2018

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

matthewbauer commented Sep 21, 2018

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

@matthewbauer matthewbauer added this to the 18.09 milestone Sep 21, 2018
@matthewbauer matthewbauer added 6.topic: darwin Running or building packages on Darwin 6.topic: haskell 1.severity: blocker This is preventing another PR or issue from being completed 0.kind: regression Something that worked before working no longer 8.has: port to stable A PR already has a backport to the stable release. labels Sep 21, 2018
@matthewbauer
Copy link
Member

matthewbauer commented Sep 21, 2018

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

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

@lrworth
Copy link
Contributor Author

lrworth commented Sep 22, 2018

Thanks, that works for me.

@LnL7
Copy link
Member

LnL7 commented Sep 25, 2018

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

@lrworth
Copy link
Contributor Author

lrworth commented Sep 26, 2018

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

build also fails with the same message.

@Ericson2314
Copy link
Member

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

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

@lrworth
Copy link
Contributor Author

lrworth commented Nov 9, 2018

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

@TomMD
Copy link

TomMD commented Nov 19, 2018

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

matthewbauer commented Nov 30, 2018

Hi all!

I believe I have found the issue here. We add the -liconv flag as a setup hook since 9e75fb5. 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 matthewbauer added 9.needs: port to stable A PR needs a backport to the stable release. and removed 8.has: port to stable A PR already has a backport to the stable release. labels Dec 2, 2018
@matthewbauer
Copy link
Member

Fixed in #51455.

@nmattia
Copy link
Contributor

nmattia commented Jan 22, 2019

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

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

nmattia commented Jan 23, 2019

Thanks! I'll patch my nixpkgs for now.

@arkrost
Copy link

arkrost commented Feb 7, 2019

Same issue for ghc 8.6.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: regression Something that worked before working no longer 1.severity: blocker This is preventing another PR or issue from being completed 6.topic: darwin Running or building packages on Darwin 6.topic: haskell 9.needs: port to stable A PR needs a backport to the stable release.
Projects
None yet
Development

No branches or pull requests

8 participants