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

stack install fails on FreeBSD 12.0-Current #3515

Closed
noinia opened this issue Oct 25, 2017 · 37 comments
Closed

stack install fails on FreeBSD 12.0-Current #3515

noinia opened this issue Oct 25, 2017 · 37 comments

Comments

@noinia
Copy link

@noinia noinia commented Oct 25, 2017

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
@noinia noinia changed the title stack build fails on FreeBSD 12.0-Current stack install fails on FreeBSD 12.0-Current Oct 25, 2017
@mgsloan mgsloan added this to the Support milestone Oct 25, 2017
@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Oct 25, 2017

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.

Loading

@noinia
Copy link
Author

@noinia noinia commented Oct 25, 2017

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?

Loading

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Oct 25, 2017

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 30, 2017

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 :)

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 30, 2017

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 31, 2017

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.

Loading

@noinia
Copy link
Author

@noinia noinia commented Nov 3, 2017

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

Thanks @myfreeweb !

Loading

@hxw
Copy link

@hxw hxw commented Dec 7, 2017

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Dec 7, 2017

@hxw yeah yeah. use system ghc.

Loading

@simonmichael
Copy link
Contributor

@simonmichael simonmichael commented Feb 17, 2018

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 ?

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Feb 17, 2018

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Feb 17, 2018

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

Loading

@borsboom
Copy link
Contributor

@borsboom borsboom commented Feb 18, 2018

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!

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Feb 18, 2018

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…

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Aug 16, 2018

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?

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Aug 16, 2018

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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Oct 9, 2018

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.

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 9, 2018

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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Oct 9, 2018

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 9, 2018

bootstraps that are used to compile lang/ghc port

Oh, sure.

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

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Oct 9, 2018

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.

Loading

@noinia
Copy link
Author

@noinia noinia commented Oct 9, 2018

It all seems to boil down to two things:

  1. 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).
  2. 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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Oct 9, 2018

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

Loading

@unrelentingtech
Copy link
Contributor

@unrelentingtech unrelentingtech commented Oct 9, 2018

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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Oct 10, 2018

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.

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Feb 10, 2019

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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Feb 11, 2019

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

Loading

@dbaynard
Copy link
Contributor

@dbaynard dbaynard commented Feb 11, 2019

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

Loading

@dbaynard dbaynard closed this Feb 11, 2019
@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Mar 17, 2019

@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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Mar 17, 2019

@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).

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Mar 17, 2019

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

  1. Create a new FreeBSD 12.0 jail on my dev system.
  2. Use your ports tree (from https://github.com/arrowd/freebsd-ports/tree/hs-overhaul).
  3. 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?

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Mar 18, 2019

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

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Mar 18, 2019

@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.

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Apr 22, 2019

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.

Loading

@arrowd
Copy link
Contributor

@arrowd arrowd commented Apr 22, 2019

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

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Apr 22, 2019

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

Loading

@duncan-bayne
Copy link

@duncan-bayne duncan-bayne commented Apr 22, 2019

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants