stack install fails on FreeBSD 12.0-Current #3515

noinia · 2017-10-25T15:10:16Z

General summary/comments (optional)

I'm having trouble building/installing packages with stack (1.5.1, installed using the official port) on FreeBSD 12.0-Current. Essentially, building any package fails with:

    Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2: No cabal file found.
    Please create a package description file <pkgname>.cabal

It does not seem to matter whether I try to build a local project using 'stack build', or install a particular package with 'stack install '. Nor does it seem matter which stackage release/version of ghc I use: I've tried with lts-9.* and ghc-8.0.2 (installed by stack), lts-* and ghc installed using the port, and the nightly snapshots with ghc 8.2.1 (installed by stack). Any idea what is going on here?

Steps to reproduce

rm ~/.stack
stack setup
stack install fgl --verbose

Expected

stack installs the package fgl.

Actual

See the full output here

Stack version

frank@UU# stack --version
Version 1.5.1 x86_64
Compiled with:
<see full output linked above>

Method of installation

Via the freebsd port in devel/stack

frank@UU# pkg info stack
stack-1.5.1
Name           : stack
Version        : 1.5.1
Installed on   : Tue Oct 24 16:00:14 2017 CEST
Origin         : devel/stack
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : haskell devel
Licenses       : BSD3CLAUSE
Maintainer     : tobik@FreeBSD.org
WWW            : http://www.haskellstack.org/
Comment        : Cross-platform program for developing Haskell programs
Shared Libs required:
	libgmp.so.10
	libiconv.so.2
	libcharset.so.1
Annotations    :
	repo_type      : binary
	repository     : local
Flat size      : 49.2MiB
Description    :
Stack is a cross-platform program for developing Haskell projects.
It is aimed at Haskellers both new and experienced. 

WWW: http://www.haskellstack.org/

system:

frank@UU# uname -a 
FreeBSD UU.FStaals.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r324496: Wed Oct 11 09:22:17 CEST 2017     root@UU.FStaals.net:/usr/obj/usr/src/sys/GENERIC  amd64

The text was updated successfully, but these errors were encountered:

mgsloan · 2017-10-25T18:02:15Z

Curious! What happens if you clone a package with no deps, say, http://github.com/aelve/microlens ?

Please post the log of it running with -v. It may also be helpful to copy out the invocation of Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 and try it manually. Guessing it's failing on configure.

noinia · 2017-10-25T22:19:59Z

I cloned the microlens repo and tried to run 'stack install -v' in the microlens/microlens directory. (I did not blow away my entire .stack folder again before testing, but somehow I doubt that would make a difference). The full output is in this gist. Seems to be the same problem.

Running Cabal-simple manually just produces the same output as in the stack invocation:

frank@UU# /home/frank/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-1.24.2.0 configure --with-ghc=/home/frank/.stack/programs/x86_64-freebsd/ghc-8.0.2/bin/ghc --with-ghc-pkg=/home/frank/.stack/programs/x86_64-freebsd/ghc-8.0.2/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/frank/.stack/snapshots/x86_64-freebsd/lts-9.10/8.0.2/pkgdb --package-db=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/pkgdb --libdir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/lib --bindir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/bin --datadir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/share --libexecdir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/libexec --sysconfdir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/etc --docdir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/doc/microlens-0.4.8.1 --htmldir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/doc/microlens-0.4.8.1 --haddockdir=/home/frank/tmp/microlens/microlens/.stack-work/install/x86_64-freebsd/lts-9.10/8.0.2/doc/microlens-0.4.8.1 --dependency=base=base-4.9.1.0 --enable-tests --enable-benchmarks
Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2: No cabal file found.
Please create a package description file <pkgname>.cabal

anything else I can try?

mgsloan · 2017-10-25T22:42:27Z

@noinia Strange! Must be a cabal bug, I suggest reporting it to https://github.com/haskell/cabal

unrelentingtech · 2017-10-30T18:38:30Z

I've been seeing this for a while… just realized — not seeing files! That must be the awesome new 64-bit inodes (and related changes) in 12-CURRENT that break everything. (I recently fixed that in Crystal; hacks are required in Rust because they don't have OS version conditionals yet.)

This is not a cabal bug.

Looks like GHC picks up the structures from C headers so there are no Rust-like problems. Stack just needs to provide GHC builds compiled on 12 for >=12.0 users. All 11 binaries are broken in terms of filesystem access. Changing inode size does that :)

unrelentingtech · 2017-10-30T19:57:15Z

Oh — and stack itself should be built on 12 too! duh. That's why it didn't work when @noinia tried ghc from ports.

unrelentingtech · 2017-10-31T00:19:16Z

So stack from pkg/ports should be built on 12 already, but just in case, my build (xz compressed)

And!! You need to run rm -rf ~/.stack/setup-exe-cache to clean up the old cached setup executables. I had them from before the inode changes landed.

noinia · 2017-11-03T11:55:09Z

Ah indeed, if I use stack with system-ghc, both built locally from ports, then I can successfully build and install packages.

Thanks @myfreeweb !

hxw · 2017-12-07T08:49:49Z

Looks like stack setup downloads a 9.3 compiled ghc (on TrueOS) so that is probably why I get the same error

% uname -rsv
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #1 67a4643eb(trueos-master): Wed Nov  8 18:09:27 UTC 2017     root@chimera:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
% cd ~/.stack/programs/x86_64-freebsd/ghc-8.0.2/lib/ghc-8.0.2/bin
% file ghc
ghc: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 9.3, not stripped

unrelentingtech · 2017-12-07T10:02:19Z

@hxw yeah yeah. use system ghc.

simonmichael · 2018-02-17T07:47:41Z

Thanks for figuring this out. I wonder where it needs to be fixed. The stack installer ? The ghc binaries stack installs ? Two sets of binaries required for old and new freebsd ? setup-exe-cache to be flushed automatically if found to contain too-old freebsd executables ?

unrelentingtech · 2018-02-17T10:37:10Z

@simonmichael yes, 12 requires ghc compiled on 12, and cache should be flushed.

unrelentingtech · 2018-02-17T10:42:49Z

also #1026 would've helped a lot (stack setup building a new ghc from source, using system ghc)

borsboom · 2018-02-18T13:06:15Z

It sounds like a first step might be include the FreeBSD version in the setup-info OS key, like we do for OpenBSD (see 3cd92c8). Then we could provide different bindists for different FreeBSD versions (and, since the caches are indexed by OS key, this would also invalidate the cache). That should be pretty easily to implement, and a pull request would be most welcome!

unrelentingtech · 2018-02-18T14:43:20Z

Oh that's already implemented for OpenBSD? Nice.

bindings-uname-0.1 seems broken?? sysname returns FreeBSD but release returns f and nodename returns E. Nothing in the source has hardcoded offsets or anything…

arrowd · 2018-08-16T10:00:23Z

I have fixed bindings-uname on FreeBSD and sent the patch to author, but didn't get response yet. Maybe we can push this some other way?

unrelentingtech · 2018-08-16T14:40:49Z

I guess you can release it as a new package. Or send a PR to stack that puts the module right here in this repo, since it's a tiny module.

arrowd · 2018-10-09T08:39:44Z

The proper solution for this is just building bindists on least supported FreeBSD version (10.4 ATM). I reported this to GHC upstream and 8.6.1 should already be fine.

unrelentingtech · 2018-10-09T13:01:36Z

Hm. They were compiled on some 9.x, and now they will be on 10.4, how would this fix 12?

You can still use old functions that take old (32-bit-inode based) structs by linking to versioned (@FBSD_1.x) symbols, e.g.: https://github.com/rust-lang/libc/blob/41944d5c37ef53647c09ac92cdb4bf636840dfab/src/unix/bsd/freebsdlike/mod.rs#L1096

BUT all built binaries, including Stack itself should be done like that. When the Haskell C FFI stuff would look at system headers, it'd find the new (64-bit inode) structs!

The real solution should be building binaries on 12 for >=12 users.

arrowd · 2018-10-09T13:06:45Z

Hm. They were compiled on some 9.x, and now they will be on 10.4, how would this fix 12?

GHC bootstraps that are used to compile lang/ghc port are built on 10.4 and work on 12. But when you are compiling GHC on 12, you need to apply the workaround you mention. It is done automatically in ports Makefile: https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=markup#l230

unrelentingtech · 2018-10-09T13:09:24Z

bootstraps that are used to compile lang/ghc port

Oh, sure.

But this thread is about the official binaries downloaded by Stack.

arrowd · 2018-10-09T13:17:44Z

Stack gets these binaries from GHC upstream, but we (FreeBSD) can also provide them. However, judging by bindist names at https://downloads.haskell.org/~ghc/8.6.1/ the upstream also uses ports to build GHC.

noinia · 2018-10-09T19:50:16Z

It all seems to boil down to two things:

There need to separate builds of GHC for (<12) and for (>= 12) that are available for download somewhere (preferably from the GHC website I guess).
Stack needs to figure out on which version of FreeBSD it is running, and use that information to figure out which version of GHC it needs to download.

as myfreeweb also stated; I don't think changing the GHC builder to FreeBSD 10.4 does anything that helps here.

arrowd · 2018-10-09T20:48:34Z

Again, GHC compiled on 10.4 works everywhere. Why do we need separate builds?

unrelentingtech · 2018-10-09T23:33:06Z

GHC compiled on 10.4 works everywhere

For very limited definitions of "works" I think. You mentioned:

when you are compiling GHC [with the 10.4 as bootstrap] on 12, you need to apply the workaround

— this is because the 10.4 compiler does not produce correct binaries on 12 — and this applies not just to bootstrapping GHC, but to compiling anything.

arrowd · 2018-10-10T08:47:21Z

Ah, you are right. I somehow missed that wrap hack is applied to the bootstrap compiler, not resulting one.

Ok, then I either need to reroll #4269 or come up with solution that would allow running pre-ino64 GHC on 12 too.

duncan-bayne · 2019-02-10T21:24:39Z

Can I help in any way? I don't have any Haskell but do know FreeBSD reasonably well, and I can set up a development environment for anyone working on this issue to use.

arrowd · 2019-02-11T06:55:18Z

This is already fixed, I'm just waiting a new Stack release.

dbaynard · 2019-02-11T14:04:55Z

@duncan-bayne If you want to get involved I'm sure @arrowd can find something for you!

duncan-bayne · 2019-03-17T11:53:29Z

@arrowd It looks like the stack port doesn't have a maintainer:

➜  ~ sudo pkg install -y stack
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	stack: 1.7.1_1

Number of packages to be installed: 1

The process will require 50 MiB more space.
[1/1] Installing stack-1.7.1_1...
[1/1] Extracting stack-1.7.1_1: 100%
Message from stack-1.7.1_1:

===>   NOTICE:

The stack port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:

https://bugs.freebsd.org/bugzilla

More information about port maintainership is available at:

https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port

Are you waiting on someone in particular for a new stack release? If not, it may be a while in coming.

I'd be happy to put my hand up to maintain the port, except that I have literally never used Haskell before, except as a consumer of shellcheck and git-annex.

arrowd · 2019-03-17T13:34:08Z

@duncan-bayne Due to specifics of how current stack port is built, it is very hard to pull in patches that enable FreeBSD 12+ support.

However, I'm working on changing the way Haskell ports are built in my local branch, and there stack port has both needed patches and corrent MAINTAINER field set to haskell@FreeBSD.org.

If you want to help me with this - you can test if ports from my branch are working for you. The good candidate is devel/hs-git-annex - you've been using it before and it has undergone significant changes. Same go for devel/stack and textproc/hs-pandoc. Bonus points for testing various OPTIONS combinations (run make config to set them).

duncan-bayne · 2019-03-17T20:47:45Z

@arrowd I can certainly test that. To be clear, my plan is:

Create a new FreeBSD 12.0 jail on my dev system.
Use your ports tree (from https://github.com/arrowd/freebsd-ports/tree/hs-overhaul).
Test that devel/hs-git-annex, devel/stack, textproc/hs-pandoc build and execute.

Are there regression tests I could run for the above ports, beyond a manual smoke test?

duncan-bayne · 2019-03-18T02:31:39Z

I can also set you up w/ SSH to access to said build system, if you'd like.

arrowd · 2019-03-18T05:52:10Z

@arrowd I can certainly test that. To be clear, my plan is:
Are there regression tests I could run for the above ports, beyond a manual smoke test?

Just test if these ports work for you as they were before.

I can also set you up w/ SSH to access to said build system, if you'd like.

That's unnecessary. Just drop me a mail if you find a bug with reproductions steps.

duncan-bayne · 2019-04-22T02:58:14Z

Works for me 👍 I took the following approach:

Created a FreeBSD 12.0 jail.
Cloned the hs-overhaul branch of https://github.com/arrowd/freebsd-ports into /usr/ports.
Built and installed the git-annex port.

I then symlinked the git-annex binary from the jail into my host /usr/local/bin. Everything is working as expected now.

arrowd · 2019-04-22T07:31:46Z

You could've done make package in the jail and then copy resulting .txz into host, and pkg add it.

duncan-bayne · 2019-04-22T09:09:11Z

@arrowd Hey, that sounds like less ongoing hassle. I'll give it a try.

duncan-bayne · 2019-04-22T12:51:15Z

... and indeed it worked nicely, just had to install the coreutils dependency beforehand. Thanks :)

noinia changed the title ~~stack build fails on FreeBSD 12.0-Current~~ stack install fails on FreeBSD 12.0-Current Oct 25, 2017

mgsloan added this to the Support milestone Oct 25, 2017

mgsloan added the resolution: upstream issue label Oct 25, 2017

simonmichael mentioned this issue Feb 17, 2018

hledger-install.sh fails on FreeBSD 12.0-current simonmichael/hledger#709

Closed

arrowd mentioned this issue Aug 17, 2018

Pull bindings-uname package into Stack and fix it to work with FreeBSD. #4238

Merged

dbaynard mentioned this issue Oct 16, 2018

Make stack setup command differentiate between FreeBSD versions. #4359

Merged

arrowd mentioned this issue Dec 12, 2018

Add bindists for FreeBSD 11 and 12. commercialhaskell/stackage-content#54

Merged

dbaynard closed this Feb 11, 2019

EarlGray mentioned this issue Apr 21, 2019

Basic support for images: XKCD-enabled! chrisdone/vado#3

Merged

commercialhaskell / stack Public

stack install fails on FreeBSD 12.0-Current #3515

stack install fails on FreeBSD 12.0-Current #3515

Comments

noinia commented Oct 25, 2017

General summary/comments (optional)

Steps to reproduce

Expected

Actual

Stack version

Method of installation

mgsloan commented Oct 25, 2017

noinia commented Oct 25, 2017

mgsloan commented Oct 25, 2017

unrelentingtech commented Oct 30, 2017 • edited Loading

unrelentingtech commented Oct 30, 2017

unrelentingtech commented Oct 31, 2017 • edited Loading

noinia commented Nov 3, 2017

hxw commented Dec 7, 2017

unrelentingtech commented Dec 7, 2017

simonmichael commented Feb 17, 2018 • edited Loading

unrelentingtech commented Feb 17, 2018

unrelentingtech commented Feb 17, 2018

borsboom commented Feb 18, 2018

unrelentingtech commented Feb 18, 2018

arrowd commented Aug 16, 2018

unrelentingtech commented Aug 16, 2018

arrowd commented Oct 9, 2018

unrelentingtech commented Oct 9, 2018 • edited Loading

arrowd commented Oct 9, 2018

unrelentingtech commented Oct 9, 2018

arrowd commented Oct 9, 2018

noinia commented Oct 9, 2018

arrowd commented Oct 9, 2018

unrelentingtech commented Oct 9, 2018

arrowd commented Oct 10, 2018

duncan-bayne commented Feb 10, 2019

arrowd commented Feb 11, 2019

dbaynard commented Feb 11, 2019

duncan-bayne commented Mar 17, 2019

arrowd commented Mar 17, 2019

duncan-bayne commented Mar 17, 2019

duncan-bayne commented Mar 18, 2019

arrowd commented Mar 18, 2019

duncan-bayne commented Apr 22, 2019

arrowd commented Apr 22, 2019

duncan-bayne commented Apr 22, 2019

duncan-bayne commented Apr 22, 2019

unrelentingtech commented Oct 30, 2017 •

edited

Loading

unrelentingtech commented Oct 31, 2017 •

edited

Loading

simonmichael commented Feb 17, 2018 •

edited

Loading

unrelentingtech commented Oct 9, 2018 •

edited

Loading