simonmar / ghc-paths Goto Github PK

Tried to build ghc-paths on macOS 13.0 (M1 Mac), but got the following error:

$ cabal build
Build profile: -w ghc-9.2.2 -O1
In order, the following will be built (use -v for more details):
 - ghc-paths-0.1.0.12 (lib:ghc-paths) (first run)
cabal: Failed to build ghc-paths-0.1.0.12. The failure occurred during the
configure step. The build process segfaulted (i.e. SIGSEGV).

Other info

$ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.2

On Hackage, there is a 0.1.0.9 release https://hackage.haskell.org/package/ghc-paths but the Cabal file on HEAD in this repo is still 0.1.0.8!

Note: I found this failure with ghc-paths-0.1.0.9, which is the latest version on Hackage. (The version in this repo is earlier, 0.1.0.8)

ghc-paths-0.1.0.9 failed during the configure step. The exception was:
user error ('/usr/local/ghc-7.10.3/bin/ghc' exited with an error:

/tmp/cabal-tmp-2009/ghc-paths-0.1.0.9/dist/dist-sandbox-4b8dde2c/setup/setup.hs:65:14:
Couldn't match type ‘(Maybe a0, [t0])’
with ‘[(ComponentName, BuildInfo)]’
Expected type: HookedBuildInfo
Actual type: (Maybe a0, [t0])
In the first argument of ‘return’, namely ‘(Just (read str), [])’
In a stmt of a 'do' block: return (Just (read str), [])
In the expression:
do { str <- readFile file;
return (Just (read str), []) }
)

I hen trying to set up taffybar (xmonad toolbar) which uses Dyre which in turn uses ghc-paths and ran into a problem.

I have a couple of different versions of GHC installed (7.4.2, 7.6.3 and 7.7) all installed under $HOME/GHC/$version and I switch between them by setting my $PATH variable. When Dyre tires to re-compile the taffybar config file, ghc-paths says that the ghc binary is at "/usr/lib/ghc/bin/ghc-7.6.3" when it is actually at $HOME/GHC/7.6.3/bin/ghc-7.6.3.

I use a shim around ghc https://gitlab.com/fommil/ghc-env which allows me to control the ghc executable that I use on a per-project basis. This is inspired by how the JVM world manages the version of Java.

However, I encountered a problem when using doctest sol/doctest#209 where its invocation of ghc was being resolved to the shim's script rather than the symbolic link to the shim script. That means the shim doesn't know what is being invoked (e.g. ghci and others also point at the shim).

It was hypothesised (in the referenced ticket) that symbolic link resolving is happening inside ghc-paths.

I would be happy to provide a PR to fix this, as it likely impacts many tools. But I wonder if there is a reason why it is the way that it is. Could you please let me know if you foresee any problems with removing the link resolution?

When I build ghc-paths on my system, it uses the following path for docdir:

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m GHC.Paths
Prelude GHC.Paths> docdir
Loading package ghc-paths-0.1.0.9 ... linking ... done.
"/nix/store/p01hdsfn3hhkwynwa32zi2y01sch2pa7-ghc-7.6.3/share/doc/ghc/html/libraries/base-4.6.0.1"

Judging from the logic I see in Setup.hs, I guess that this should really come out as:

/nix/store/p01hdsfn3hhkwynwa32zi2y01sch2pa7-ghc-7.6.3/share/doc/ghc/html

Or do I misunderstand the intended result?

Hi - the change from #13 will be strictly needed when Cabal 3.0 and GHC 8.8 become things. Currently, it's in no released version. It's not pressing at the moment, but at some point in the near future a release would be quite handy, please.

As part of building eta, http://eta-lang.org/docs/html/getting-started.html, the build from source fails with the following error:

ghc-paths-0.1.0.9: configure
Progress: 1/2
-- While building package ghc-paths-0.1.0.9 using:
/tmp/stack20200/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.5.0 configure --with-ghc=/home/miki/.stack/programs/x86_64-linux/ghc-nopie-7.10.3/bin/ghc --with-ghc-pkg=/home/miki/.stack/programs/x86_64-linux/ghc-nopie-7.10.3/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/miki/.stack/snapshots/x86_64-linux-nopie/lts-6.27/7.10.3/pkgdb --package-db=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/pkgdb --libdir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/lib --bindir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/bin --datadir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/share --libexecdir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/libexec --sysconfdir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/etc --docdir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/doc/ghc-paths-0.1.0.9 --htmldir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/doc/ghc-paths-0.1.0.9 --haddockdir=/home/miki/git/eta/.stack-work/install/x86_64-linux-nopie/lts-6.27/7.10.3/doc/ghc-paths-0.1.0.9 --dependency=Cabal=Cabal-1.22.8.0-39a93ef541e462ed7a7da08beca21643 --dependency=base=base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d --dependency=directory=directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97
Process exited with code: ExitFailure 1
Logs have been written to: /home/miki/git/eta/.stack-work/logs/ghc-paths-0.1.0.9.log

[1 of 2] Compiling Main             ( /tmp/stack20200/ghc-paths-0.1.0.9/Setup.hs, /tmp/stack20200/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.5.0/setup/Main.o )
[2 of 2] Compiling StackSetupShim   ( /home/miki/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack20200/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.5.0/setup/StackSetupShim.o )
Linking /tmp/stack20200/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.5.0/setup/setup ...
Configuring ghc-paths-0.1.0.9...
setup: The program 'eta' is required but it could not be found.

Build env: stack: 1.4.0 on Ubuntu: 16.10.
Is this a ghc-paths issue?

Setup

MacOS Mojave 10.14.2, Xcode-10.1, current Macports with a lot of tools ("ports") installed, current Haskell Platform (ghc-8.6.3), current cabal and stack.

In short

stack fails to build intero because it fails to build ghc-paths. Which fails, because somehow ghc-paths is the only package (or one of the few) that does not accept (or doesn't make use of) parameters like ---ghc-options -optL=/usr/lib/libiconv.dylib.

This came up in rikvdkleij/intellij-haskell#375

Log

Shown in the attempt to build intero:
intero-build.txt

The long story

Problem: Macports provides it's own version of libiconv.dylib, and it mangles function names - so it cannot be used in place of the Apple-provided libiconv.dylib. Standard ghc (or rather, libHSbase.a, which is a part of the GHC binary package) is linked against the Apple-provided libiconv.dylib.

For most packages (of for everything other than ghc-paths), adding --ghc-options -optL=/usr/lib/libiconv.dylib to the stack invocation seems to suffice to force the linker to take the correct shared library (to use /usr/lib/libiconv.dylib instead of /opt/local/lib/libiconv.dylib that precedes it on the library search path - which it must for reasons I don't want to get into here). But with ghc-paths it does not work.

Since all of my stack config files add the options I listed, but I cannot find it in the actual log - I suspect that something in the ghc-paths forces certain build flags. If that's correct - it would have to be relaxed to fix this problem.

Executing `/usr/local/bin/stack build intero` failed: /usr/local/bin/stack build intero: ghc-paths-0.1.0.9: configure -- While building package ghc-paths-0.1.0.9 using: /usr/local/bin/ghc --make -odir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -hidir /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/Users/uri/.stack/snapshots/x86_64-osx/lts-13.3/8.6.3/pkgdb -package-db=/Users/uri/src/p-test2/.stack-work/install/x86_64-osx/lts-13.3/8.6.3/pkgdb -hide-all-packages -package-id=Cabal-2.4.1.0-Df4rkGuWEtO4aZs4eesJ3r -package-id=base-4.12.0.0 -package-id=directory-1.3.3.0 -optP-include -optP/private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup_macros.h /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/Setup.hs /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup -threaded Process exited with code: ExitFailure 1 Logs have been written to: /Users/uri/src/p-test2/.stack-work/logs/ghc-paths-0.1.0.9.log [1 of 2] Compiling Main ( /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/Setup.hs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/Main.o ) /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/Setup.hs:29:18: warning: [-Wdeprecations] In the use of ‘rawSystemProgramStdoutConf’ (imported from Distribution.Simple.Program): Deprecated: "use getDbProgramOutput instead. This symbol will be removed in Cabal-3.0 (est. Mar 2019)." | 29 | libdir_ - rawSystemProgramStdoutConf (fromFlag (configVerbosity flags)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ [2 of 2] Compiling StackSetupShim ( /Users/uri/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/StackSetupShim.o ) Linking /private/var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/stack57338/ghc-paths-0.1.0.9/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup ... Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding_closure, _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_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure ) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.12.0.0.a(iconv.o) (maybe you meant: _hs_iconv_close) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.12.0.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)

Note: with cabal I can build ghc-paths and install intero. But that doesn't help with my problem, as the IDE plugin I'm using, only understand `stack projects.

Your help is requested in resolving this.

Thanks!

ghc-paths has a number of releases, 0.1, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.1.0.4, 0.1.0.5, 0.1.0.6, 0.1.0.7, 0.1.0.8, 0.1.0.9, 0.1.0.12,
but misses a CHANGELOG that would explain the rationales for the different releases. (E.g. it is not clear to me whether I need to bound the version of ghc-paths from below in my projects.)

Please add a CHANGELOG.

The problem with this library is that it bakes the absolute path of the GHC installation into the compiled binary, but then if the binary is copied to another computer, the GHC installation might be in a different path and the binary won't work.

I propose that this library should transparently read from an environment variable called GHC_HOME first, if it exists then use that, otherwise fallback to the compiled-in path.

Other languages have a similar environment variable, for example: JAVA_HOME and PYTHONHOME.

The current workaround is to simply write the code yourself to read from GHC_HOME environment var and then fallback to ghc-paths, but having the code in this library would help to standardize my proposed GHC_HOME environment variable throughout the Haskell ecosystem.

Btw, if you are going to ask your users to set a GHC_HOME environment variable, then why use this library at all in the first place? Well, during development and for running unit tests it is convenient to not have to set any configuration, so using ghc-paths is good, but then it would be nice if the same binary would also transparently and automatically be portable via an environment variable setting.

Thank you

This is not really an issue, but more of a request for information since I couldn't find much info on this module's purpose on the internet.

It seems to me that this module exists so that paths to key ghc executables are available to GHC and possibly other libraries/packages, which is obvious by looking at the module source.

However, this strikes me as a code smell that could make deployment more brittle than it should. In addition, Cabal's auto generated _Paths.hs seems to use the same mechanism and, if I am not mistaken, this is one open issue in the context of being able to deploy multiple instances of the same package version (deterministic ABI hashes).

I lack the historical and the detailed knowledge of the ramifications of changes here, but were there other alternatives considered such as a $GHC_HOME environment variable? Or specific reasons why that would not work?

This question also extends to _Paths.hs module generated by Cabal: should data files known at compilation be packaged with the .a (ar archive) and then backed into and served from the final executable? This would remove the need to have (at least) some of these hard coded paths.