I'm trying to install the ghc-mod library on Windows. Using stack install ghc-mod shows this lengthy error message:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for ghc-mod-5.8.0.0:
Cabal-2.4.1.0 from stack configuration does not match >=1.18 && <1.25 (latest matching version is 1.24.2.0)
base-4.12.0.0 from stack configuration does not match >=4.6.0.1 && <4.10 (latest matching version is 4.9.1.0)
cabal-helper must match <0.8 && >=0.7.3.0, but the stack configuration has no specified version (latest matching
version is 0.7.3.0)
djinn-ghc must match <0.1 && >=0.0.2.2, but the stack configuration has no specified version (latest matching
version is 0.0.2.3)
extra-1.6.17 from stack configuration does not match <1.6 && >=1.4 (latest matching version is 1.5.3)
ghc-8.6.5 from stack configuration does not match >=7.6 && <8.2
ghc-syb-utils must match <0.3 && >=0.2.3, but the stack configuration has no specified version (latest matching
version is 0.2.3.3)
haskell-src-exts-1.20.3 from stack configuration does not match <1.20 && >=1.18 (latest matching version is 1.19.1) hlint-2.1.11 from stack configuration does not match <2.1 && >=2.0.8 (latest matching version is 2.0.15)
monad-journal-0.8.1 from stack configuration does not match <0.8 && >=0.4 (latest matching version is 0.7.2)
optparse-applicative-0.14.3.0 from stack configuration does not match >=0.13.0.0 && <0.14 (latest matching version
is 0.13.2.0)
temporary-1.3 from stack configuration does not match <1.3 && >=1.2.0.3 (latest matching version is 1.2.1.1)
needed since ghc-mod is a build target.
Some different approaches to resolving this:
* Build requires unattainable version of base. Since base is a part of GHC, you most likely need to use a different
GHC version with the matching base.
Apparently, I need to change the version of ghc, but my version is higher than the one required, so updating doesn't help. Should I downgrade? How to do it without messing up the rest of my ghc ecosystem?
Using cabal to install it gives similar results.
Sorry, but you can't do this unless you are willing to downgrade to GHC 8.0. Note in the dependencies list it says ghc (>=7.6 && <8.2). There is no GHC 8.1 (odd numbers are for testing), so its back to GHC 8.0.
Stackage provides a curated list of package versions which are known to compile together, along with a version of GHC. Each Long Term Support (LTS) is a specific set of these versions. As you can see from the list posted by Damián Rafael Lattenero that means going back to LTS-9.21.
The problem is that ghc-mod uses GHC as a library as well as a compiler, so it is very sensitive to the version, and you have to use the same version of the compiler for both ghc-mod and the software you are developing; having got a working version of ghc-mod you can't just switch to a later version of GHC for your own program.
Assuming you still want to do this, get stack installed. Then edit your ~/.stack/config.yaml file (on Windows type stack path --stack-root to find where this is stored). Change it to say resolver: lts-9.21. Then say stack install ghc-mod.
In stackage you can find all the LTS versions and all the possible releases you can download:
and here is the list of all the dependencies you need for ghc-mod:
You need to check that you don't have any outdated or unmatched.
Related
I need a pre build project and I need a version of protoc-gen-go v1.25.0-devel but I am unable to find command etc to install It , till now I tried to do something like this :
go get -u google.golang.org/protobuf/cmd/protoc-gen-go#v1.25.0-devel
and I am getting this ERROR invalid version: unknown revision cmd/protoc-gen-go/v1.25.0-devel
Is there any way to get this version ?
If you're following this post to create a sample service, you don't need the specific version 1.25.0-devel that appears in the generated files. You should use the latest stable version (currently v1.26.0). Since it is an minor version upgrade, there should be no breaking changes between versions. One thing that you may need to make the examples in the post to work is that you should set the package for the generated code. You can set it in the .proto file as an option, for example option go_package = grpc-example/generated/protos/calc or as a command line argument for the protoc command, for example protoc ...OTHER_OPTS --go_opt=Mprotos/calc.proto=grpc-example/generated/protos/calc.
If you are sure that you absolutely need the specific version v1.25.0-devel you can install the plugin pointing to a specific commit (as that version is not currently available as a tag/branch name). If you're using go 1.16.x you can use go install google.golang.org/grpc/cmd/protoc-gen-go-grpc#a9513eb pointing at this commit. For older go versions, use go get
I committed a change to Haskell's opaleye project that I need for a project I am working on. The change is in version 0.6.7003.1, which has not propagated to the nixos repository yet (nixos.org shows its current version to be 0.6.7001.0).
Since this needed dependency differs from the the resolver's LTS version, I have marked the extra dependency in stack.yaml:
packages:
- git#github.com:tomjaguarpaw/haskell-opaleye.git
- commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
I have also marked this version in the build-depends of my project.cabal file:
build-depends: opaleye >= 0.6.7003.1 && < 1
When I then attempted to build, I got the following error:
$ stack build
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for taskmaster-0.1.0.0:
opaleye must match >=0.6.7003.1 && <1, but the stack configuration has no specified version (latest matching version is 0.6.7003.1)
needed since taskmaster is a build target.
Some different approaches to resolving this:
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many
complicated constraint errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /home/matthew/backup/taskmaster/taskmaster/stack.yaml:
opaleye-0.6.7003.1#sha256:914ac99c6f7ceea050df843ac31c33be0f6340bc0f05753c8fdfc18074fa9e5b
Plan construction failed.
(I do not understand where this long (>40 char) sha256 hash comes from).
I followed the advice and added the following to my stack.yaml.
extra-deps:
- opaleye-0.6.7003.1#sha256:914ac99c6f7ceea050df843ac31c33be0f6340bc0f05753c8fdfc18074fa9e5b
When I run $ stack build to build my project, the compiler attempts to build without showing any dependency errors. However, it strikes a type error that it would not if it were using the version of Opaleye containing my change. And, when I run $ stack ghci and import a relevant opaleye module, my change is not present. It appears that somehow stack is still using an older opaleye version. How can I get stack to use the more recent version of opaleye containing my change?
My attempts seem to have exhausted the options mentioned in the haskell-stack documentation.
The hackage option is usually better than the github extra-dep.
The correct syntax for what you initially tried would be
extra-deps:
- git: https://github.com/tomjaguarpaw/haskell-opaleye.git
commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
and the github: tomjaguarpaw/haskell-opaleye version is just a shortcut.
The sha256 hash is the sha256sum of the cabal file corresponding to that version (and revision) of opaleye.
Given that version of opaleye is already on hackage, you should just be able to add the line suggested by stack. You may wish to try a stack clean after you make the change (though it shouldn't be necessary).
If you present more information, I'll update this answer.
It turned out that stack's extra-deps suggestion was incorrect. I noticed an alternative format under this stack github issue, gave it a try, and it happened to work for me. The working extra-deps format is listed below.
extra-deps:
- github: tomjaguarpaw/haskell-opaleye
commit: cf3296c5ffef58d36dd6b386ae53dff519ee47e9
Just got started with Nix (version 2.2.1), and while installing darcs (version 2.14.1) i encountered my first problem: I get the following error message (preceded by the callstack):
Setup: Encountered missing dependencies:
base >=4.9 && <4.12,
network >=2.6 && <2.8,
stm >=2.1 && <2.5,
zip-archive ==0.3.*
I have the haskell tool stack installed as well as a global ghc (though both should not be needed to build darcs i think).
I also had no problem with installing darcs with 'apt'
Am i making a classic nix beginner mistake or whats going on here?
Nix is very different from package managers like 'apt'. Derivations (which are like packages) are designed to be built in an isolated environment, where the derivation is responsible for providing its own dependencies by referencing other derivations. Because of this, you do not need to explicitly install anything in order to build a package.
Note also that although Nixpkgs uses the Cabal library to build Haskell packages, installing a package via Nix is quite different from installing with cabal-install. In fact it is closer to Stack, because Nixpkgs defines its haskellPackages based on stackage and it avoids cabal-style dependency resolution. It does however let you use the Cabal solver to check whether the dependencies match the versions specified in the cabal files. This check can be disabled using the doJailbreak function in Nixpkgs.
I don't think we need to get into the details of Haskell packaging in Nixpkgs though, because you should be able to get a pre-built darcs from the nixos-18.09 channel. The Nix expression from the nixos-unstable produces exactly your error message.
I recommend you to use the latest release channel, nixos-18.09, because nixos-unstable will break regularly. See the Nix manual for changing your channel configuration.
I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
I am trying to run an app but I get
...
/usr/lib64/libstdc++.so.6: VERSION 'GLIBCXX_3.4.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.14' not found
...
When I do "strings /usr/lib64/libstdc++.so.6 | grep GLIBC" i get a normal list...
...
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
...
GLIBCXX_3.4.13
GLIBCXX_2.2.5
GLIBCXX_2.3.2
...
I don't seem to find a simple tutorial on how to install the missing libs/files/dependencies, (or Centos 6.5 or anything else for that mater).
Can someone explain how to install whatever might be missing on Centos?
Can someone explain how to install whatever might be missing on Centos?
You need glibc >= 2.15 and libstdc++ >= 3.4.15.
In theory, installing e.g. glibc-2.19 on the system should work (glibc provides backward binary compatibility), but this message suggests that you would not find a standard package for your OS with such an upgrade.
Instead you would have to either install a second version of glibc, as documented here, and redirect your application to use that version by binary-patching the loader encoded into the application, or run your application in a chroot (where you can install any version of glibc you like).
Similar considerations apply to libstdc++.so.6 as well, except you don't have to install it into the fixed location -- you can install newer copy anywhere, and point LD_LIBRARY_PATH to it.
Your final (and most likely easiest) alternative is to build the app you are trying to run from source, or obtain a pre-built binary for your distribution (one that doesn't require newer libraries than what you have).