I tried to install system-fileio to my global package db and failure was :
c:\Haskell\2013.2.0.0\bin>cabal-1.20.0.1.exe install system-fileio
Resolving dependencies...
Configuring system-fileio-0.3.13...
Building system-fileio-0.3.13...
Failed to install system-fileio-0.3.13
Last 10 lines of the build log ( C:\Users\bitli\AppData\Roaming\cabal\logs\system- fileio-0.3.13.log ):
The import of `System.IO.Error' is redundant
except perhaps to import instances from `System.IO.Error'
To import instances alone, use: import System.IO.Error()
lib\hssystemfileio-win32.c: In function 'hssystemfileio_copy_permissions':
lib\hssystemfileio-win32.c:10:17:
error: storage size of 'st' isn't known
lib\hssystemfileio-win32.c:11:2:
warning: implicit declaration of function '_wstat64'
cabal-1.20.0.1.exe: Error: some packages failed to install:
system-fileio-0.3.13 failed during the building phase. The exception was:
ExitFailure 1
I tried it on Windows 7.
I just ran into this same problem on Windows 7 with system-fileio-0.3.13, using both the windows command line with Haskell Platform 2013.2.0.0's built-in mingw and also inside msys with a newer mingw64. The problem appears to be caused by a change introduced between system-fileio-0.3.12 and system-fileio-0.3.13. system-fileio's git repo doesn't seem to have a web interface to link to, but 0.3.12's lib\hssystemfileio-win32.c uses:
struct _stat st;
int rc = _wstat(old_path, &st);
while 0.3.13's hssystemfileio-win32.c has changed to:
struct _stat64 st;
int rc = _wstat64(old_path, &st);
Copying 0.3.12's hssystemfileio-win32.c over top of 0.3.13's does seem to allow it to build, though I don't know if it actually functions correctly.
I don't know if this will work for you, but I'm trying to build yesod on Windows 7 (inside a sandbox with an upgraded cabal-install from the one in the Haskell Platform) and I extracted a system-fileio 0.3.13 tarball from Hackage, copied 0.3.12's hssystemfileio-win32.c over, and then did a cabal sandbox add-source ../system-fileio-0.3.13 inside my yesod sandbox. My cabal install of yesod could then proceed and seems to have worked. If you're doing a system install of system-fileio, you probably should be able to just build in the extracted and modified system-fileio-0.3.13 directory directly.
I'm sure someone who knows something about Haskell and cabal will be able to provide a proper solution instead of this hack.
Related
I've been trying to compile the Kadena chainweb-node project from source (via the docs found here) in a docker container running the arm64v8/ubuntu base image on an Apple M1 host machine and I keep getting errors. Thanks to the super helpful folks in the #haskell IRC channel, I've made it over a number of small hurdles, but the build still fails with:
Undefined symbol: ossl_sha3_512_functions
I can not find any resources on how to fix this but one of the #haskell community members informed me that these symbols are not provided by the openssl 3.0 API. That person created an issue here: https://github.com/larskuhtz/hs-hashes/issues/14
I've found that I can use the docker base image haskell:8 which comes preinstalled with ghc, cabal, and openssl 1.1.1 to cabal build chainweb-node successfully using a slightly different set of apt-get dependencies. However, when trying to cabal install the binaries so that I can run chainweb-node, I get:
Failed to build chainweb-2.14.1. The failure occurred during the configure
step.
Build log (
/root/.cabal/logs/ghc-8.10.7/chainweb-2.14.1-36aedf5adc1967eb17358e6434b6fd51bc7e64082f6c12e0df40ddafece6ff69.log
):
[1 of 1] Compiling Main ( /tmp/cabal-install.-838/dist-newstyle/tmp/src-838/chainweb-2.14.1/dist/setup/setup.hs, /tmp/cabal-install.-838/dist-newstyle/tmp/src-838/chainweb-2.14.1/dist/setup/Main.o )
Linking /tmp/cabal-install.-838/dist-newstyle/tmp/src-838/chainweb-2.14.1/dist/setup/setup ...
Configuring chainweb-2.14.1...
setup: Encountered missing or private dependencies:
criterion -any,
data-ordlist >=0.4.7,
resource-pool >=0.2,
retry >=0.7,
statistics >=0.15,
tasty-json >=0.1
cabal: Failed to build chainweb-2.14.1. See the build log above for details.
I've tried cabal install criterion and the other missing deps, one by one, but the cabal install gives me the same errors.
Can someone tell me what I'm doing wrong and help me get a working chainweb-node binary built from source and installed using docker?
I installed the timezone-series Haskell module using cabal install timezone-series-0.1.5.1.
I then defined a module named Main.hs that starts with:
import Data.Time.LocalTime.TimeZone.Series -- from timezone-series-0.1.5.1
when I run ghc Main.hs, GHC throws the following error:
/home/ubuntu/Main.hs:2:1: error:
Failed to load interface for ‘Data.Time.LocalTime.TimeZone.Olson’
I tried explicitly including the cabal directory in GHC's search path using:
ghc -i/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/ Main.hs
This resulted in the correct path being searched, but GHC is only looking for files ending in the suffix ".hs":
Locations searched:
...
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hsig
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhsig
Cabal installed interface files instead however:
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Olson.hi
From line 318 of GHC's source code it looks like GHC ignores "*.hi" files unless it is called in single-shot mode (with the -c flag). Is this correct? (See: https://github.com/ghc/ghc/blob/67a5a91ef5e61f3b3c84481d8a396ed48cd5d96e/compiler/GHC/Unit/Finder.hs)
How can I get GHC to import this module?
An help will be greatly appreciated!
My suggested ways of installing packages in order of my preference:
Make a cabal package and add timezone-series you want to install to the build-depends field as described in the cabal manual.
Use the experimental cabal-env tool to basically automate the process of point 3 below, but then with the global environment. This makes a new build-plan every time you install a new package, so it is like removing the package environment and building it again with all the old packages and the new package added to it. You can add specific constraints like this: cabal-env "timezone-series == 0.1.5.1".
Install a package into local package environment with cabal --package-env . --lib timezone-series. You can add as many packages as you want after the --lib option to install more than one package. If you later want to use a different set of packages simply remove the .ghc.environment.* file that is generated and rerun the installation with a new set of packages. GHC will automatically use these package environment files that are in the current or parent directories. You can specify specific constraints with the --constraint option like this: --constraint "timezone-series == 0.1.5.1".
Use cabal install --lib timezone-series to install it directly into the global environment (~/.ghc/x86_64-linux-8.0.2/environments/default), this will fail if a conflicting package was installed earlier. When you run into errors you can remove that package environment and try again.
Finally, I want to note that GHC 8.0.2 is quite old, so I would advise you to upgrade if you don't have a specific reason for using that version.
I am new to GTK, but not to Haskell. I am currently running Arch linux.
I cloned gi-gtk-declarative, and did a checkout of the release-0.6.3 branch.
I tried compiling with both stack build and cabal v2-build all, and both fail on gi-glib with the following error:
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
How can I fix this? Is there a patched version of gi-glib?
This looks like an issue regarding version constraints:
gi-gtk-declarative depends on haskell-gi (>=0.21 && <0.24)
Looks like this issue was fixed on haskell-gi 0.24.4
As you can see, the author of gi-gtk-declarative needs to update his dependencies.
As a workaround, you can run stack build --allow-newer or cabal build --allow-newer which will bypass the version constraint.
I tried running my program which uses Haskell QuickCheck via ghc MyProgramm.hs , but received the following error:
$ ghc Ex2.hs
[1 of 1] Compiling Ex2 ( Ex2.hs, Ex2.o )
Ex2.hs:21:1: error:
Could not find module ‘Test.QuickCheck’
There are files missing in the ‘QuickCheck-2.11.3’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
21 | import Test.QuickCheck (
| ^^^^^^^^^^^^^^^^^^^^^^^^...
I installed stack, ran stack update and stack install QuickCheck without issue but the error persisted. Then, I ran cabal install QuickCheck and got the following errors:
$ cabal install QuickCheck
Resolving dependencies...
Configuring QuickCheck-2.12.4...
Building QuickCheck-2.12.4...
Failed to install QuickCheck-2.12.4
Build log ( /home/username/.cabal/logs/ghc-8.4.3/QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK.log ):
cabal: Entering directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
Configuring QuickCheck-2.12.4...
Preprocessing library for QuickCheck-2.12.4..
Building library for QuickCheck-2.12.4..
[ 1 of 16] Compiling Test.QuickCheck.Exception ( Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )
[ 2 of 16] Compiling Test.QuickCheck.Random ( Test/QuickCheck/Random.hs, dist/build/Test/QuickCheck/Random.o )
Test/QuickCheck/Random.hs:10:1: error:
Could not find module ‘System.Random’
There are files missing in the ‘random-1.1’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
10 | import System.Random
| ^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:11:1: error:
Could not find module ‘System.Random.TF’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
11 | import System.Random.TF
| ^^^^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:12:1: error:
Could not find module ‘System.Random.TF.Gen’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
12 | import System.Random.TF.Gen(splitn)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cabal: Leaving directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
cabal: Error: some packages failed to install:
QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK failed during the building phase. The
exception was:
ExitFailure 1
However, I already have the arch packages haskell-random, haskell-tf-random and haskell-mwc-random installed. Does anybody know how to fix this?
Edit: I also ran cabal install random --reinstall.
Problem
On Archlinux as of 2022-09-17, pacman -S ghc cabal-install will install
system packages that provide only dynamic files (.so, .dyn_hi) in
installed packages inside /usr/lib/ghc-*; static files (.a, .hi) are (for
the most part) missing. However, the default cabal configuration enables static file
building. Unfortunately, upstream cabal-install doesn't track whether or not
static files are available inside installed packages. It just assumes they
are, and when they are gone, it fails with errors such as you have found:
[1 of 1] Compiling Main ( Main.hs, ../setup.dist/work/depender/dist/build/depender/depender-tmp/Main.o )
Main.hs:3:1: error:
Could not find module `Dynamic'
There are files missing in the `dynamic-1.0' package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
| import qualified Dynamic (number)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Workaround
A quick workaround just to get up and running quickly is to disable static file
building, which is by default enabled. (Note that trying to pass package-local
flags to disable static file with e.g. --enable-shared --enable-executable-dynamic --disable-library-vanilla (which is how most if
not all current Archlinux Haskell packages seem to build packages, e.g. with
https://github.com/archlinux/svntogit-community/blob/master/haskell-scientific/trunk/PKGBUILD)
building using cabal-install may be ignored due to another, related bug; but
~/.cabal/config is a safe bet.) You may do so by adding 3 lines to
~/.cabal/config in the appropriate location:
library-vanilla: False
shared: True
executable-dynamic: True
(Alternatively, consider using alternative tools like stack.)
More complete solution
For a more long-term solution, one option involves 2 pieces: 1) one or more
system packages that provide all types of build artifacts, static and dynamic,
for the base, foundational packages (from GHC and cabal-install), at least as an option besides dynamic-only packages (secondary Haskell packages are optional,
since cabal-install can rebuild these with needed build artifacts (static or
dynamic)), and 2) patching cabal-install (and ghc-pkg, which can handle .conf
files recording information about installed packages) to track whether static
files are available, and to be aware of these when resolving dependencies so
that cabal-install knows when to prefer rebuild a source package with needed
build artifact configuration over an already installed package that doesn't
provid required build artifacts.
There is a merge request (I submitted) that provides such a patchset, called
fix-dynamic-deps, at https://github.com/haskell/cabal/pull/8461. For users
running into exactly the problem that you described (myself included), I also
created an AUR package that provides both pieces based on GHC 9.4.2 with Cabal
3.9.0.0 that includes my patchset (there is a mirror at
https://github.com/bairyn/ghc-cabal-arts.) It provides ghc and
cabal-install but includes both of these pieces.
Further reading
Here are a few more resources I wrote on or are related to this bug:
https://wiki.archlinux.org/index.php?title=Haskell&diff=745459&oldid=738269#Troubleshooting
https://github.com/haskell/cabal/pull/8461
https://github.com/bairyn/ghc-cabal-arts
https://github.com/bairyn/cabal/tree/fix-dynamic-builds
Even though I have a main = do and couldn't get it working that way, I was able to run my QuickCheck test as follows:
To run a quickCheck, first load your program with:
$ ghci MyProg.hs
Then to run the quickCheck, find the test you want to run, then run it with:
$ quickCheck my_quick_check
https://travis-ci.org/Fresheyeball/fbatch
Preprocessing library monad-parallel-0.5...
Control/Monad/Parallel.hs:67:8:
Could not find module `Control.Monad.Identity'
It is a member of the hidden package `mtl-2.2.1'.
Perhaps you need to add `mtl' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
monad-parallel-0.5 failed during the building phase. The exception was:
ExitFailure 1
I am new to haskell, and just can't seem to get past this. I've tinkered with my .cabal file all I can, and the sub dependency fails on Travis every time.
Please help.
If a build fails while resolving a dependency, it's worth having a look a what version of that package gets installed. Normally, cabal should default to the most recent possible, which if well-maintained should install fine. Older versions do of course often mean trouble, if some dependency of theirs has now a newer, incompatible version installed.
In your case, cabal tried to install the somewhat ancient monad-parallel-0.5, which imports a module that doesn't exist in transformers (namely Control.Monad.Identity). The more recent version 0.7.1.2 does not try this and thus builds successfully. You can force such a recent install by giving a lower bound to the dependency in your .cabal file, in this case monad-parallel >= 0.7.