Open erikd opened 8 years ago
It looks like setting some hans flags fixed this?
It it was just Hans, I've added an issue for it (#28). It seems to be a frequent problem, and if there's some way to clean it up we should do it.
Seems I'm getting this compiler warning
src/Tor/Link.hs:396:38: Warning:
Fields of ‘Supported’ not initialised: supportedEmptyPacket
In the ‘clientSupported’ field of a record
In the expression:
ClientParams
{clientUseMaxFragmentLength = Nothing,
...
even with ghc 7.10.3. I'll try and fix this first and then try again with ghc ghc-8.0.1.
Its not possible to build haskell-tor with GHC 8.0 until https://github.com/haskell/cabal/issues/3701 is fixed. Ghc 8.0 requires cabal-install >= 1.24.0.0.
https://github.com/haskell/cabal/issues/3701 was not a bug in cabal, but rather undefined behavior in the dependency solver. The undefined behavior can be avoided using:
cabal install --dependencies-only --enable-tests --constraint="tls +hans" \
--constraint="haskell-tor +hans"
I made an attempt to build haskell-tor in a cabal sandbox with GHC 8.0.1 on a Debian box. I started with a stackage snapshot of cabal.config and later updated it with cabal freeze
. The result is here: https://github.com/GaloisInc/haskell-tor/pull/32
I had a quick look at building haskell-tor with ghc-8.0.1 and quickly ran into a minefield of problems.
The first problem was that the versions of
cryptonite
andmemory
specified in the cabal file specify the version ofbase
that is less than what ships with 8.0. Then, if I bump those dependencies, cabal warns (--dry-run
mode in a sandbox)which I have never seen before and do not understand.
Even if I ignore all that and use
--force-reinstalls
(its a sandbox right?) the dependencies build ok, but then theTor.Link
module fails to compile, because there are undefined fields in theClientParams
struct. I can't find that struct in the haskell-tor sources, and can't figure out where else its coming from.So, what are the plans for making this build with ghc-8.0?