search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
4k stars 843 forks source link

`--install-ghc` fails on FreeBSD #3267

Open mqudsi opened 7 years ago

mqudsi commented 7 years ago

Running the "official" stack installed from the binary package manager on FreeBSD 10.3-RELEASE, stack 1.4.0 x86_64

If GHC isn't separately already installed via the FreeBSD package manager, the usage of --install-ghc results in the following:

[I] mqudsi@php ~/conffmt> stack build --install-ghc
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-7.10.3.
Running /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3.temp/ghc-7.10.3/configure --prefix=/usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3/ in directory /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3.temp/ghc-7.10.3/ exited with ExitFailure 1

checking for path to top of build tree...
Shared object "libutil.so.8" not found, required by "ghc-pwd"
configure: error: cannot determine current directory

Error: Error encountered while configuring GHC with
         /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3.temp/ghc-7.10.3/configure --prefix=/usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3/
         run in /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3.temp/ghc-7.10.3/

The following directories may now contain files, but won't be used by stack:
  - /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3.temp/
  - /usr/home/mqudsi/.stack/programs/x86_64-freebsd/ghc-7.10.3/

Configuring GHC ...⏎
Blaisorblade commented 7 years ago

Hypothesis: the GHC bindist in use is for the wrong FreeBSD version (very likely) and is not compatible? What's the FreeBSD binary compatibility policy, if any?

That's a problem we're facing with OpenBSD—there, it turned out we need to consider the OS release when picking which bindist to use—see https://github.com/commercialhaskell/stack/pull/3184.

borsboom commented 7 years ago

Previous versions of GHC just had one FreeBSD bindist, with a README that says:

This bindist tarball was built on 9.3-RELEASE. But it can be used on the latest releases of the 10.x and 11.x branches as well — that is, it works on 9.3-RELEASE, 10.3-RELEASE, and 11.0-RELEASE. It may work on 12-CURRENT, but your milage may vary.

However, GHC 8.2.1 has different bindists for FreeBSD 10.3 and FreeBSD 11. Stack doesn't currently have any logic to select a bindist based on the release, so I think it's defaulting to the 10.3 bindist. It shouldn't be too hard to add that logic, since we're already doing similar things when detecting gmp4 vs. gmp10 Linux distributions.

Blaisorblade commented 7 years ago

@borsboom That all makes sense, but in itself doesn't explain the OP's error, does it? The OP is using versions that should be supported.

riaqn commented 6 years ago

Hello, when will this issue be fixed? Or is there some workaround we can use?

borsboom commented 6 years ago

The best workaround is probably to install FreeBSD's GHC package and use stack --system-ghc (or the equivalent option in ~/.stack/config.yaml).

Ultimately we'll need a FreeBSD user/developer to investigate the cause of this error. In theory, the GHC 7.10.3 bindist is supposed to FreeBSD 10.3-RELEASE, so why it wouldn't work on this particular system is a mystery. I'd probably start by trying to manually install the bindist and see how far that gets.

mqudsi commented 6 years ago

FreeBSD’s ABI is guaranteed stable within major versions only, with best effort compatibility otherwise. But it’s not a question of ABI - if it were compiled under 9.3 it would be dynamically linked against an older version of libutil. ABI stability is enough only for statically linked binaries.

borsboom commented 6 years ago

Makes sense, so Stack should be more selective about which bindist it tries to install and give an error message if it can't find a known-compatible one (like we do for Linux and OpenBSD already). Two approaches possible here:

  1. Go by the FreeBSD version. Add a suffix to the OS keys with the FreeBSD major and minor version, and use that to look up the correct bindist. This is how it works for OpenBSD, so the same approach would be quite easy to use for FreeBSD.

  2. Detect versions of dynamically linked libraries, and use those to find a bindist linked with compatible versions. This is more like what we do for Linux with libtinfo/libncurses and libgmp.

I lean toward (1), I think it's easier to implement and less likely to end up with unexpected behaviour in the future.

Note that this won't actually fix the original issue (it won't make it possible to install a GHC bindist built for an incompatible version of FreeBSD), but it will at least give a sensible error message instead, and will let us support multiple FreeBSD versions if there are multiple GHC bindists to support them.

borsboom commented 6 years ago

A PRs to do this would be most welcome. See #3184 (which Paolo already linked above) for reference, since that did the same thing for OpenBSD. I think you'd just have to add another case for FreeBSD here. It will also involve updating the setup-info YAML to add the version suffixes (this can be tested locally using stack setup --setup-info-yaml=<PATH>).