FreeBSD support and installation instructions

[varosi]

It would be great if there is FreeBSD support for stack, too.

[borsboom]

Have you tried it? In theory, Stack should work just fine on FreeBSD.

It wouldn't be hard to start distributing binaries for FreeBSD either, since there are official GHC bindists available. Basically all we'd need is a Vagrantfile in https://github.com/commercialhaskell/stack/tree/master/etc/vagrant that sets up the environment in which a binary gets built. A pull request would be welcome.

We'd also be very open to anyone who wants to contribute Stack packages/ports to FreeBSD. We can provide any help needed, and would also be willing to take over maintenance for new Stack versions once the legwork to get it all set up has been done.

[varosi]

I'm not much proficient in BSD. I have tried to build it via cabal without Stackage config without success. I should try with Stackage. I'll try with vagrant, too. Thanks!

[borsboom]

This seems to work for building stack on a fresh FreeBSD VM:

sudo pkg install ghc hs-cabal-install ca_root_nss
cabal install ignore -f without-pcre # This won't be needed for stack >0.1.6.0
cabal install stack

This stack seems to work fine using the system-installed GHC.

However, there's an issue that blocks us distributing stack binaries for FreeBSD, which need to support stack setup: the GHC bindist's defaults for ./configure don't seem to work quite right. Here's what I did on another fresh FreeBSD VM with the just the stack executable I built earlier (but no system-installed GHC):

sudo pkg install ca_root_nss compat8x-amd64 gmake perl5 gcc libiconv
stack setup

When you build Haskell code after this, there are a lot of clang: warning: argument unused during compilation warnings. According to the GHC bindist's README:

Although GHC may work with Clang, it is recommended to use GCC from the Ports Collection until the Clang support receives more testing on FreeBSD.

$ env CC=gcc48 ./configure --with-gcc=gcc48 --with-ld=/usr/local/bin/ld --prefix=$PREFIX

I guess we could teach stack setup to pass these arguments to the bindists's configure?

[cmoore]

Here are links to the FreeBSD bindists on GHC's download site for 7.10.3. Strangely, they're not in the initial yellow box listing the supported OSs, but the download links are there.

freebsd64:
http://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3-x86_64-portbld-freebsd.tar.bz2

(not sure the key for this in the metadata, but this is 32 bit)
http://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3-i386-portbld-freebsd.tar.bz2

While I love lts-3.20, it'd be nice to upgrade :)

I'll just send a PR for stackage-content.

commercialhaskell/stackage-content#16

[borsboom]

Does stack setup actually work with the 7.10.3 FreeBSD bindist? Last time I tried there were problems because the ./configure step needed extra arguments that Stack wasn't providing.

[berdario]

I tried to run stack setup on FreeBSD 10.2-RELEASE-p9 and it failed due to a missing libutils.so.8

Running /tmp/stack-setup13907/ghc-7.10.3/configure --prefix=/home/dario/.stack/programs/x86_64-freebsd/ghc-7.10.3/ in directory /tmp/stack-setup13907/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

There's a /lib/libutil.so.9 on my system, so I presume that maybe the bindists have been built on an older version of FreeBSD?

(OTOH, using stackage lts 3.22, which sports GHC 7.10.2, and thus using the system's ghc, it seems to work fine)

[cmoore]

Yep, I had to install compat8x and compat9x from pkg to get things going on 10.2.

@borsboom

Yes, the metadata for stack has been updated so now stack setup should work like you expect.

I've built a pkg repository for stack and FreeBSD here: http://stack-pkg.applicative.tech/

Build tools are here in case anyone is interested: https://github.com/applicative-tech/stack-pkg

[borsboom]

This looks great! If you don't mind, I'd like to look into integrating this with our standard release process and hosting the packages on our S3 bucket. I didn't have a chance to do this for the just-released stack-1.0.4, unfortunately.