Override -Werror when installing from Cabal - haskell

I'm trying to install the nano-hmac-0.2.0 package (a dependency of a package I want) from Hackage using Cabal and GHC 6.12.1, but it fails with the following error:
Data/Digest/OpenSSL/HMAC.hsc:1:0:
Warning: Module `Prelude' is deprecated:
You are using the old package `base' version 3.x.
Future GHC versions will not support base version 3.x. You
should update your code to use the new base version 4.x.
<no location info>:
Failing due to -Werror.
Sure enough, the package's .cabal file has the following line in it:
ghc-options: -Wall -Werror -O2 -fvia-C
I'd like to be able to override the -Werror option so I can install the package without manually modifying the .cabal file, but can't find a way that will work. In particular, I tried passing --ghc-options to Cabal to stick a -Wwarn in GHC's argument list, like this:
$ cabal install nano-hmac-0.2.0 -v2 --ghc-options='-Wwarn'
This doesn't do what I want, though; the verbose output verifies that -Wwarn is getting added to the beginning of GHC's argument list, but the -Werror from the .cabal file appears later and seems to override it:
/usr/bin/ghc -Wwarn --make -package-name nano-hmac-0.2.0 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-3.0.3.2-0092f5a086872e0cdaf979254933cd43 -package-id bytestring-0.9.1.5-125aff5b9d19ec30231ae2684b8c8577 -O -Wall -Werror -O2 -fvia-C -XForeignFunctionInterface -XBangPatterns -XCPP Data.Digest.OpenSSL.HMAC
I also tried passing --constraint='base >= 4' to Cabal to force it to use a more recent version of base and avoid the warning entirely, but I get the same failure, and I still see the following in the verbose output:
Dependency base ==3.0.3.2: using base-3.0.3.2
Is there a way to get rid of or override the -Werror coming from the .cabal file via the Cabal command line, or am I stuck modifying the .cabal file myself?

Is there a way to get rid of or override the -Werror coming from the .cabal file via the Cabal command line, or am I stuck modifying the .cabal file myself?
Indeed. There's no way in general. You may be able to override package constraints such that the warnings go away, however, in general, you must modify the .cabal file.
These days Hackage prevents people uploading packages with -Werror in their .cabal file, so the issue will go away over time.

Related

Removing dependency on Terminfo package from a GHC compiled binary

I'd like to remove terminfo package from the default dependencies of my GHC installation, as the generated executable does not run in a particular environment without libtinfo, saying:
./Main: error while loading shared libraries: libtinfo.so.6: cannot
open shared object file: No such file or directory
So, is there any neat way to remove dependency on terminfo package?
The only way I found is to use -hide-all-packages of ghc and then enumerate all required default packages via -package option:
ghc -hide-all-packages -package-db ~/.cabal/store/ghc-8.10.7/package.db \
-package base -package containers -package array -package template-haskell \
-package unix -package filepath -package process -package directory \
-package time --make Main.hs
Options like -hide-package or -ignore-package doesn't work.
$ ghc -ignore-package terminfo -ignore-package ghc --make Main.hs
Loaded package environment from /home/keigoi/.ghc/x86_64-linux-8.10.7/environments/default
<command line>: cannot satisfy -package-id ghc-8.10.7:
ghc-8.10.7 is ignored due to an -ignore-package flag
(use -v for more information)
Any ideas?
Some thoughts and additional findings:
(*) I have no idea why the generated binary depends on it -- the package is required by GHC API, which is not always necessary I think and I didn't use it.
Actually, binaries generated from the fresh installation (as of GHC 8.10 or 9.2 from ghcup) does not depend on libtinfo.
Under the circumstance that ~/.ghc/x86_64-linux-8.10.7/environments/default does not exist, the generated binary has no dependency to libtinfo. This file is generated when you initialize Cabal. After that, the compiled binary will depend on libtinfo.so.
(**) Commands like strip seems not to elimite that dependency.

How do I disable `-Werror` only when compiling as a library?

I have
ghc-options:
- -Wall
- -Werror
in my package.yaml and it builds fine for GHC 8.6.
But when using the project in a GHC 9 codebase, it errors because of an unnessessary MonadFail import.
How can I change the library such that it won't abort compilation when used in other projects?
I have tried
ghc-options:
"$everything": -Wwarn
in the downstream (dependent) project, but that doesn't seem to affect it. I expected -Wwarn to override the -Werror since $everything should cover even dependencies.
I believe, it is bad practice to specify -Werror on the library itself. Same goes for other compiler flags, such as optimization for example -O2.
Setting -Wall on the other hand is definitely good stuff, plus a few other warning flags of top of my head, eg. -Wincomplete-record-updates, -Wincomplete-uni-patterns, -Wredundant-constraints, etc.
If you want to turn build warnings into errors while working on the library or in CI, which is a sensible thing to do, then you can enable it in your
stack.yaml:
ghc-options:
my-library: -Werror
cabal.project:
package my-library
ghc-options: -Werror
That being said you can turn off -Werror for any library downstream by setting -Wwarn for that library in the exact same fashion as above, which will override the original flag.

How to link custom object file with Haskell library?

I've created a Haskell package that makes FFI calls to functions defined in CUDA code. I'd like to compile .cu file to an object (.o) file during package build and force linker to link it in.
So far, I tried to use a technique found this question. I've customized buildHook to:
run nvcc
run default buildHook
create ar library file with nvcc compiled code.
Setup.hs is available here.
This solution has a major disadvantage in restricting this package to static linking. Although cabal produces a shared library, it won't work because it has no way of resolving symbols located in the object file.
Is there a simpler way to link custom code during building?
I do a similar thing. I have a Haskell file which calls CUDA code.
Here's how I compile CUDA libraries and link with Haskell:
$(NVCC) -c -E $(NVCC_OPTS) -o build/file.i file.cu
$(NVCC) -c $(NVCC_OPTS) -o build/file.o file.cu
I then link everything into a C++ Shared Library called LibSO with Haskell options
$(CXX) -shared -Wl,-rpath=\$$$$ORIGIN $(CXX_LINK_LIBS) $(PACKAGE_RPATH) -Lbuild -rdynamic -L/usr/local/lib/ghc-7.6.3 -lHSrts-ghc7.6.3 -o build/LibSO.so build/file.o
where
CXX_LINK_LIBS = -Lbuild -lcudart -lcuda -lpthread -lcupti -lcurand -lnvidia-ml
NVCC_OPTS = --compiler-options -fPIC -maxrregcount=0 --machine 64 --DCUDA
I then take my Haskell files and compile them into o and hi files. (I compile twice because of TemplateHaskell)
ghc -v0 -Wall -rtsopts -threaded -stubdir build -ibuild/ -no-hs-main -o build/iop.o -ohi build/iop.hi -c haskell/iop.lhs
ghc -v0 -Wall -rtsopts -threaded -stubdir build -ibuild/ -no-hs-main -fPIC -dynamic -osuf dyn_o -hisuf dyn_hi -o build/iop.dyn_o -ohi build/iop.dyn_hi -c haskell/iop.lhs
So now we have haskell dynamic objects and a C++ shared library.
In the end, I link a main haskell file with everything:
ghc -optl "-Wl,-rpath=\$$ORIGIN" $(CXX_LINK_LIBS) -Lbuild -rtsopts -threaded -lstdc++ -lLibSO -o build/Main build/iop.dyn_o
Does this sort of help?

Haskell - can't find package

I have a package installed via cabal: Data.Vector
But when I attempt to compile a program that has import Data.Vector in it:
Drews-MacBook-Pro:Blokus-AI drewgross$ ghc --make -O2 -prof -auto-all playGame
Grid.hs:28:8:
Could not find module `Data.Vector'
Perhaps you meant
Data.Tensor (from Tensor-1.0.0.1)
Data.Functor (from base)
Use -v to see a list of the files searched for.
Drews-MacBook-Pro:Blokus-AI drewgross$
The command I used to install was:
cabal install -p --reinstall --force-reinstalls vector
I've done other various thing in my attempt to get my program to compile, but nothing has worked. I'd really like to just delete everything, go back to square one and download the package again. How can I do that?
Edit: further investigation shows that there might be 2 versions of Data.Vector: 0.10.0.1 and 0.9.1, maybe they are conflicting somehow?
Edit: ghc-pkg check lists no errors, but gives me a ton of warnings that look like this:
Warning: haddock-interfaces: /Users/drewgross/.cabal/share/doc/haskell-lexer-1.0/html/haskell-lexer.haddock doesn't exist or isn't a file
Edit: GCHi also doesn't find it
λ> import Data.Vector
<no location info>:
Could not find module `Data.Vector'
Perhaps you meant Data.Functor (from base)
λ>
Edit: ghc-pkg list vector:
Drews-MacBook-Pro:Blokus-AI drewgross$ ghc-pkg list vector
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/package.conf.d
/Users/drewgross/.ghc/x86_64-darwin-7.4.2/package.conf.d
vector-0.10.0.1
Drews-MacBook-Pro:Blokus-AI drewgross$
and building with -v flag:
Drews-MacBook-Pro:Blokus-AI drewgross$ ghc --make -O2 -prof -auto-all -v playGame
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.4.2
Using binary package database: /usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d/package.cache
Using binary package database: /Users/drewgross/.ghc/x86_64-darwin-7.4.2/package.conf.d/package.cache
package Cabal-1.16.0.3-e689d8e77b2f476229954cd43b1737bd is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd directory-1.1.0.2-72e928d14fc50f31f7e6404839a15691 unix-2.5.1.1-29636eb78541401e8e00393ef5df097e
package Tensor-1.0.0.1-a8f1a59665c3ebc4867678a14fe1460f is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package binary-0.5.1.1-e62c39c3aba8093e9b9655a4a8d2bce9 is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd bytestring-0.10.0.1-9b03e69060669eabf0b20e150305c7be
package bmp-1.2.3.2-c7572ec2bbb802bfd93fed0953c61d5d is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd binary-0.5.1.1-e62c39c3aba8093e9b9655a4a8d2bce9 bytestring-0.10.0.1-9b03e69060669eabf0b20e150305c7be
package bytestring-0.10.0.1-9b03e69060669eabf0b20e150305c7be is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package ghc-paths-0.1.0.9-4e6c624a3431a4fa7630e4fb77be4c83 is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package haskell-lexer-1.0-8fea1c35b626a2de761522690a88c063 is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package primitive-0.4.1-0007d441db5f4ce1ffd66bd3816c2d4e is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package split-0.2.1.1-03ec5738edb34f2e8967d25637b9392f is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
package vector-0.10.0.1-3450daae3d9f2092020075d05481123c is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd primitive-0.5.0.1-15cdc8c11a54a78809b647af0c2975b3
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-7d3c2c69a5e8257a04b2c679c40e2fa7
wired-in package integer-gmp mapped to integer-gmp-0.4.0.0-af3a28fdc4138858e0c7c5ecc2a64f43
wired-in package base mapped to base-4.5.1.0-47f48c3ae7f8256a66a23e9dfe22eefc
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.7.0.0-e109822dcbed82c43f9fa60194eb64b5
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -fscc-profiling -static
*** Chasing dependencies:
Chasing modules from: *playGame.hs
Grid.hs:28:8:
Could not find module `Data.Vector'
Perhaps you meant Data.Functor (from base)
Locations searched:
Data/Vector.hs
Data/Vector.lhs
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
Drews-MacBook-Pro:Blokus-AI drewgross$
This is what shell uses:
Drews-MacBook-Pro:Blokus-AI drewgross$ which ghc
/usr/bin/ghc
I did cabal install -v lens and obviously there was a ton of output but I think this is the relevant part:
Registering lens-3.7.0.2...
/usr/bin/ghc-pkg update - --global --user
Updating world file...
Drews-MacBook-Pro:Blokus-AI drewgross$
Which seems to indicate that they are using the same version. I can post more of the output of a cabal install if its relevant.
Edit: more ghc output from cabal install -v
Building lens-3.7.0.2...
Preprocessing library lens-3.7.0.2...
Building library...
creating dist/build
/usr/bin/ghc --make -package-name lens-3.7.0.2 -hide-all-packages -fbuilding-cabal-package -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-DTRUSTWORTHY=1 -optP-DDEFAULT_SIGNATURES=1 -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id array-0.4.0.0-0b6c5ca7e879a14d110ca4c001dd9297 -package-id base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd -package-id bytestring-0.9.2.1-0044644a71adfe5e950e6c6f6ca13065 -package-id comonad-3.0.0.2-6ef27fce8536ebdf9c364307a0915f63 -package-id comonad-transformers-3.0-a6df581636b1c9b514cfa6560f17d6a3 -package-id comonads-fd-3.0-b906ed7898871c5d2427052e2eefa62e -package-id containers-0.4.2.1-75f143aa39a3e77a1ce2300025bdd8ce -package-id filepath-1.3.0.0-f998e5510c76a98913f57b14b4f16c57 -package-id ghc-prim-0.2.0.0-7d3c2c69a5e8257a04b2c679c40e2fa7 -package-id hashable-1.1.2.5-14291f3b4e96b5599759ce7daa2bd37c -package-id mtl-2.1.2-02e701f9b1590ee88a0b5b0bd5d93a29 -package-id parallel-3.2.0.3-4cdd6067624f867b253b98d6d9fb9f52 -package-id semigroups-0.8.4.1-4d3a86b037504e6000a0354510588745 -package-id split-0.2.1.1-03ec5738edb34f2e8967d25637b9392f -package-id template-haskell-2.7.0.0-29110cc89a711d6ab3e7ee0e0a8ee949 -package-id text-0.11.2.3-473d9a1761b27c7315f2ef4569d93c3c -package-id transformers-0.3.0.0-8e66ecc7d4dae2b07b2b5406908c70e4 -package-id unordered-containers-0.2.2.1-d70d5ccb1df11dbbbaac89571b1ee46d -package-id vector-0.10.0.1-3450daae3d9f2092020075d05481123c -O -Wall -fwarn-tabs -O2 -fdicts-cheap -funbox-strict-fields -XHaskell98 Control.Lens.TH Language.Haskell.TH.Lens Control.Exception.Lens Control.Lens Control.Lens.Action Control.Lens.Classes Control.Lens.Combinators Control.Lens.Fold Control.Lens.Getter Control.Lens.Indexed Control.Lens.IndexedGetter Control.Lens.IndexedFold Control.Lens.IndexedLens Control.Lens.IndexedSetter Control.Lens.IndexedTraversal Control.Lens.Internal Control.Lens.Internal.Zipper Control.Lens.Iso Control.Lens.Loupe Control.Lens.Plated Control.Lens.Prism Control.Lens.Representable Control.Lens.Setter Control.Lens.Simple Control.Lens.Traversal Control.Lens.Tuple Control.Lens.Type Control.Lens.WithIndex Control.Lens.Wrapped Control.Lens.Zipper Control.Lens.Zoom Data.Bits.Lens Data.ByteString.Lens Data.ByteString.Strict.Lens Data.ByteString.Lazy.Lens Data.Complex.Lens Data.Data.Lens Data.Dynamic.Lens Data.HashSet.Lens Data.IntSet.Lens Data.List.Lens Data.List.Split.Lens Data.Sequence.Lens Data.Set.Lens Data.Text.Lens Data.Text.Strict.Lens Data.Text.Lazy.Lens Data.Tree.Lens Data.Typeable.Lens Data.Vector.Lens Data.Vector.Generic.Lens GHC.Generics.Lens Data.Array.Lens System.FilePath.Lens Control.Parallel.Strategies.Lens Control.Seq.Lens Control.Lens.Internal.Combinators
[ 1 of 57] Compiling Control.Lens.Classes ( src/Control/Lens/Classes.hs, dist/build/Control/Lens/Classes.o )
[ 2 of 57] Compiling Control.Lens.Internal ( src/Control/Lens/Internal.hs, dist/build/Control/Lens/Internal.o )
[ 3 of 57] Compiling Control.Lens.Internal.Combinators ( src/Control/Lens/Internal/Combinators.hs, dist/build/Control/Lens/Internal/Combinators.o )
[ 4 of 57] Compiling Control.Lens.Indexed ( src/Control/Lens/Indexed.hs, dist/build/Control/Lens/Indexed.o )
[ 5 of 57] Compiling Control.Lens.IndexedGetter ( src/Control/Lens/IndexedGetter.hs, dist/build/Control/Lens/IndexedGetter.o )
[ 6 of 57] Compiling Control.Lens.Action ( src/Control/Lens/Action.hs, dist/build/Control/Lens/Action.o )
[ 7 of 57] Compiling Control.Lens.Setter ( src/Control/Lens/Setter.hs, dist/build/Control/Lens/Setter.o )
Edit: ghc-pkg dump
Drews-MacBook-Pro:Blokus-AI drewgross$ ghc-pkg dump | grep "id: base"
id: base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
Your package database is badly broken. The ghc -v output lists ten unusable packages due to missing or recursive dependencies, among them vector:
package vector-0.10.0.1-3450daae3d9f2092020075d05481123c is unusable due to missing or recursive dependencies:
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd primitive-0.5.0.1-15cdc8c11a54a78809b647af0c2975b3
One thing all the broken packages have in common is the missing(?) dependency
base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
where the
wired-in package base mapped to base-4.5.1.0-47f48c3ae7f8256a66a23e9dfe22eefc
used base has a different hash.
I'm not sure how this came about, as far as I'm aware, it's impossible to reinstall base, but it looks like you have two exemplars of ghc-7.4.2, and they step on each other's toes.
ghc-pkg list uses
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/package.conf.d
for the global package database, while the compilation uses
Using binary package database: /usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d/package.cache
Now, it might be that at least one of the two is a symlink and they're both pointing to the same place - then your package.cache is out of sync - but
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.4.2
a GHC booted by the same version seems unusual.
Can you ascertain whether you have indeed two ghc-7.4.2 and the command line uses a different one from the one cabal uses? which ghc tells you which one the shell uses, and cabal install -v some-package outputs the command line cabal uses, including the whole path to the used GHC.
You can list your installed packages with ghc-pkg list. For example (apparently I need to update),
$ ghc-pkg list | grep vector
vector-0.9.1
vector-algorithms-0.5.4
vector-algorithms-0.5.4.2
vector-space-0.8.0
vector-strategies-0.3
You can unregister them using ghc-pkg unregister. Ex,
$ ghc-pkg unregister vector-0.9.1
And then a cabal update && cabal install vector should grab the latest version from hackage.
I had a similar problem with another module after I installed the Haskell Platform over an existing (homebrewed) ghc install [Mac OS Mavericks 10.9.+]. I uninstalled the previous ghc with homebrew
brew uninstall ghc
and re-ran the Haskell Platform installer (.pkg on Mac). I then had to
sudo ghc-pkg recache
to resolve the out-of-date warning upon
ghc-pkg list
This resolved the problem in my case.
You might want to add the package to your .cabal file

Problem Specifying Source Directory to GHC

This is an embarrassingly simple problem, but its solution yet eludes me. As the title indicates, I simply want to specify to GHC the location of all my source files. This should be simple; the GHC user guide:
-idirs
This flag appends a colon-separated
list of dirs to the search path.
So, I tried the following invocations:
ghc -isrc/ -v -outputdir build/ --make -Wall Main.hs
ghc -isrc/: -v -outputdir build/ --make -Wall Main.hs
ghc -i:src/: -v -outputdir build/ --make -Wall Main.hs
ghc -i"src/" -v -outputdir build/ --make -Wall Main.hs
ghc -i"src/": -v -outputdir build/ --make -Wall Main.hs
ghc -i:"src/": -v -outputdir build/ --make -Wall Main.hs
On every invocation GHC gave the error: "<no location info>: can't find file: Main.hs"
As you probably could have guessed, Main.hs is located in a subdirectory from the working directory called "src". Just in case it matters, I'm on Windows XP, and I'm using GHC 6.12.2. I'm assuming there is some small problem that I'm just missing.
-i specifies where GHC will search for other source files, other than the ones you specify on the command line. So your Main.hs there will also need a src/ prefix. E.g.
$ ghc -isrc src/Main.hs --make
[1 of 1] Compiling Main ( src/Main.hs, src/Main.o )
Linking src/Main ...
Alternatively, you could use cabal, and have cabal init generate all the build metadata for you.

Resources