Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upstack install fails on FreeBSD 12.0-Current #3515
Comments
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
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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:
anything else I can try? |
This comment has been minimized.
This comment has been minimized.
@noinia Strange! Must be a cabal bug, I suggest reporting it to https://github.com/haskell/cabal |
mgsloan
added
the
resolution: upstream issue
label
Oct 25, 2017
This comment has been minimized.
This comment has been minimized.
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 :) |
This comment has been minimized.
This comment has been minimized.
Oh — and stack itself should be built on 12 too! duh. That's why it didn't work when @noinia tried ghc from ports. |
This comment has been minimized.
This comment has been minimized.
So stack from pkg/ports should be built on 12 already, but just in case, my build ( And!! You need to run |
This comment has been minimized.
This comment has been minimized.
Ah indeed, if I use stack with system-ghc, both built locally from ports, then I can successfully build and install packages. Thanks @myfreeweb ! |
This comment has been minimized.
This comment has been minimized.
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
|
This comment has been minimized.
This comment has been minimized.
@hxw yeah yeah. use system ghc. |
simonmichael
referenced this issue
Feb 17, 2018
Open
hledger-install.sh fails on FreeBSD 12.0-current #709
This comment has been minimized.
This comment has been minimized.
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 ? |
This comment has been minimized.
This comment has been minimized.
@simonmichael yes, 12 requires |
This comment has been minimized.
This comment has been minimized.
also #1026 would've helped a lot ( |
This comment has been minimized.
This comment has been minimized.
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! |
This comment has been minimized.
This comment has been minimized.
Oh that's already implemented for OpenBSD? Nice.
|
This comment has been minimized.
This comment has been minimized.
I have fixed |
This comment has been minimized.
This comment has been minimized.
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
referenced this issue
Aug 17, 2018
Merged
Pull bindings-uname package into Stack and fix it to work with FreeBSD. #4238
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 ( 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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
Oh, sure. But this thread is about the official binaries downloaded by Stack. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
It all seems to boil down to two things:
as myfreeweb also stated; I don't think changing the GHC builder to FreeBSD 10.4 does anything that helps here. |
This comment has been minimized.
This comment has been minimized.
Again, GHC compiled on 10.4 works everywhere. Why do we need separate builds? |
This comment has been minimized.
This comment has been minimized.
For very limited definitions of "works" I think. You mentioned:
— 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. |
This comment has been minimized.
This comment has been minimized.
Ah, you are right. I somehow missed that Ok, then I either need to reroll #4269 or come up with solution that would allow running pre-ino64 GHC on 12 too. |
dbaynard
referenced this issue
Oct 16, 2018
Merged
Make `stack setup` command differentiate between FreeBSD versions. #4359
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
This is already fixed, I'm just waiting a new Stack release. |
This comment has been minimized.
This comment has been minimized.
@duncan-bayne If you want to get involved I'm sure @arrowd can find something for you! |
noinia commentedOct 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:
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
Expected
stack installs the package fgl.
Actual
See the full output here
Stack version
Method of installation
system: