Fails to install Haskell tools because it's using the wrong compiler

MacOS Mojave 10.14.2, IntelliJ IDEA 2018.3.3, GHC-8.6.3 (rebuilt - see below)

21:56	Executing `/usr/local/bin/stack --system-ghc -j1 --stack-root /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12 --resolver lts-12 --compiler ghc-8.4.4 --local-bin-path /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin install hoogle` failed: /usr/local/bin/stack --system-ghc -j1 --stack-root /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12 --resolver lts-12 --compiler ghc-8.4.4 --local-bin-path /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin install hoogle:   
			Selected resolver: lts-12.26
			appar-0.1.7: download
			appar-0.1.7: configure
			appar-0.1.7: build
			appar-0.1.7: copy/register
			async-2.2.1: download
			async-2.2.1: configure
			async-2.2.1: build
			async-2.2.1: copy/register
			auto-update-0.1.4: download
			auto-update-0.1.4: configure
			auto-update-0.1.4: build
			auto-update-0.1.4: copy/register
			base-orphans-0.7: download
			base-orphans-0.7: configure
			base-orphans-0.7: build
			base-orphans-0.7: copy/registe... (show balloon)

My systems have Macports installed. That makes it impossible to link static Haskell executables, because Macports introduced its own copy of libiconv.dylib that mangles function names - which in turn makes it impossible to link anything with libHSbase.a (see https://trac.macports.org/ticket/57821).

Here’s what the failure looks like:

Executing `/usr/local/bin/stack --system-ghc -j1 --stack-root /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12 --resolver lts-12 --compiler ghc-8.4.4 --local-bin-path /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin install hoogle` failed: 
/usr/local/bin/stack --system-ghc -j1 --stack-root /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12 --resolver lts-12 --compiler ghc-8.4.4 --local-bin-path /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/bin install hoogle:
 Selected resolver: lts-12.26 hoogle-5.0.17.3:
 configure hoogle-5.0.17.3: build -- 
While building package hoogle-5.0.17.3 using: /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.4 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.2.0.1 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 
Logs have been written to: /Users/uri/Library/Caches/com.github.rikvdkleij.intellij-haskell/lts-12/global-project/.stack-work/logs/hoogle-5.0.17.3.log 
Configuring hoogle-5.0.17.3... clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] Preprocessing library for hoogle-5.0.17.3.. Building library for hoogle-5.0.17.3.. [ 1 of 28] Compiling General.IString ( src/General/IString.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/IString.o ) [ 2 of 28] Compiling General.Str ( src/General/Str.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Str.o ) [ 3 of 28] Compiling General.Conduit ( src/General/Conduit.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Conduit.o ) [ 4 of 28] Compiling General.Template ( src/General/Template.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Template.o ) [ 5 of 28] Compiling General.Util ( src/General/Util.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Util.o ) [ 6 of 28] Compiling General.Timing ( src/General/Timing.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Timing.o ) [ 7 of 28] Compiling General.Log ( src/General/Log.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Log.o ) [ 8 of 28] Compiling Input.Download ( src/Input/Download.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Download.o ) [ 9 of 28] Compiling Input.Item ( src/Input/Item.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Item.o ) [10 of 28] Compiling Input.Haddock ( src/Input/Haddock.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Haddock.o ) [11 of 28] Compiling Input.Set ( src/Input/Set.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Set.o ) [12 of 28] Compiling Paths_hoogle ( .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/autogen/Paths_hoogle.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Paths_hoogle.o ) [13 of 28] Compiling Input.Settings ( src/Input/Settings.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Settings.o ) [14 of 28] Compiling Input.Reorder ( src/Input/Reorder.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Reorder.o ) [15 of 28] Compiling Input.Cabal ( src/Input/Cabal.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Input/Cabal.o ) [16 of 28] Compiling General.Store ( src/General/Store.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Store.o ) [17 of 28] Compiling Output.Types ( src/Output/Types.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Output/Types.o ) [18 of 28] Compiling Output.Names ( src/Output/Names.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Output/Names.o ) [19 of 28] Compiling Output.Items ( src/Output/Items.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Output/Items.o ) [20 of 28] Compiling Action.CmdLine ( src/Action/CmdLine.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Action/CmdLine.o ) [21 of 28] Compiling General.Web ( src/General/Web.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/General/Web.o ) [22 of 28] Compiling Query ( src/Query.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Query.o ) [23 of 28] Compiling Output.Tags ( src/Output/Tags.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Output/Tags.o ) [24 of 28] Compiling Action.Generate ( src/Action/Generate.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Action/Generate.o ) [25 of 28] Compiling Action.Search ( src/Action/Search.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Action/Search.o ) [26 of 28] Compiling Action.Server ( src/Action/Server.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Action/Server.o ) /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack66588/hoogle-5.0.17.3/src/Action/Server.hs:193:49: warning: [-Wdeprecations] In the use of ‘for’ (imported from Data.List.Extra): Deprecated: "Use flip map directly, since this function clashes with Data.Traversable.for" | 193 | showFroms local haddock xs = intercalate ", " $ for pkgs $ \p -> | ^^^ [27 of 28] Compiling Action.Test ( src/Action/Test.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Action/Test.o ) [28 of 28] Compiling Hoogle ( src/Hoogle.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Hoogle.o ) clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] Preprocessing executable 'hoogle' for hoogle-5.0.17.3.. Building executable 'hoogle' for hoogle-5.0.17.3.. [1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/hoogle/hoogle-tmp/Main.o ) Linking .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/hoogle/hoogle ... clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] 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_iconvEncoding6_info, _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_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 clang: error: linker command failed with exit code 1 (use -v to see invocation) `clang' failed in phase `Linker'. (Exit code: 1)

And here’s the log file it refers to: hoogle-log.txt

There are two solutions:

1. The one I prefer - I rebuilt GHC from sources (and put it into /opt/local/bin that precedes /usr/local/bin on the PATH), so it is linked against Macports, so it’s libHSbase.a is happy with Macports-provided libiconv.dylib.
2. Pass ghc-option /usr/lib/libiconv.dylib to each and every invocation of GHC.

My ~/.cabal/config.platform and ~/.stack/config.yaml require system-ghc, but apparently this plugin doesn’t honor it, and when it downloads a “standard” resolver with its own GHC - that GHC fails the link phase on libiconv.dylib.

What I’d like to see in this plugin:

• Ability to set/force my (system) GHC, rather than use what’s in an old resolver.
• Ability to pass parameters to GHC, stack, etc.

[mouse07410]

with their own flags ignoring the flags I’m passing to it, that things fall apart.

I still wonder if it makes sense to have setting to add extra options to stack commands because it sometimes works and sometimes not. Very confusing for future users.

1. The fault IMHO is with those (thankfully, not numerous) packages that chose to ignore the flags.
2. Other (thankfully, numerous) packages do benefit from those extra options. One can say it’s the difference between “running” and “not running”.

and have no disk space to waste on useless replications (especially with the magnitude of extra space that stack seem to require to replicate so much of the Haskell environment).

There is only GHC version per computer (when needed) 😄

There should be only one GHC version - but in my experience, stack multiplies them like viruses. 😱😤

Not to mention all the other crap stuff that it pulls in. Overall, I’ve had a few toy projects that pulled over 1GB of stuff. By my book - absolutely intolerable.

So what helps for you is that I add another setting in which user can point to alternative location of intero , which has the risk that the alternative intero is build with different GHC version as project.

YES! This risk is perfectly acceptable to me, and would be stated by the developer in the README to warn those who shouldn’t be doing that.

Can do the same for the Haskell tools binaries which has the risk that supports breaks because the API is not compatible with what plugin is expecting.

YES! Yes, please! Note, that IntelliJ already does this for most everything it provides - it detects what it can, and allows you to override those locations. So, for example, I set it to use my own Maven.

Just expose the defaults, allow user to override them, and state that risk in the README. E.g., telling the user that he shouldn’t modify the defaults unless he both understands well what the consequences could be, and has a good reason to diverge from those defaults.

Maybe in that case, automatic build upon project import won’t be necessary? And/or maybe it could be controlled by a config option, like “Do not build the project automatically”?

[mouse07410]

Yeah, it’s fine.

One problem - the current plugin does not support operations like “stack clean” (which is necessary to deal with cases when, e.g., there are artifacts stuck in the project that prevent it from running correctly). There’s no way to request such an operation, and no way to prevent plugin from forcing the executable (that it consists the right one).