Command line option --with-gcc is ignored
#4073
Comments
|
Hey there, it would be real nice to have a feedback on this! Even a "it's too low priority for use to investigate, sorry" would be nice :) |
OlivierSohn
changed the title
--with-gcc is ignored
|
Hello, this must have fallen through the cracks. I wonder if this is related to haskell/cabal#4439. @nh2 might have some idea? |
|
It may also relate to #3902 |
|
@dbaynard yes it looks like these issues are related |
|
@OlivierSohn Can you try my solution from this reddit thread which is to add to your The bug mentioned in #4073 (comment) is certainly relevant but if you are lucky it only affects a stage in cabal where it doesn't matter what the Please report back if that helps! |
|
@nh2 note that I use c++ 17, not C++ 14, and I already pass
Why do you think that passing
would make the right gcc (i.e the one I specify using the commandline option) be selected ? |
|
(continued) @nh2 in your context are you using |
|
@OlivierSohn Ah, sorry, I misunderstood, you are right. If the compiler that's slected can't do c++17 at all, then what I said won't help. A couple questions:
This link 404s for me, could you make a stable link to it? You're giving a Windows path in If yes, could you provide full instructions to trigger it? A temporary workaround might be to simply inplace-replace the GCC it's currently picking by a newer version. |
|
@nh2 Ok, and I tried the suggestion, to confirm it doesn't solve the issue. I updated the link to the .cabal (the branch was deleted in-between) I don't know if the issue is reproducible on linux : I didn't need --with-gcc on linux (I managed to upgrade the compilers in a way that doesn't require to use --with-gcc) What do you mean by "inplace-replace the GCC it's currently picking" exactly? |
@OlivierSohn That you would replace whatever |
|
@nh2 ok, maybe that could work, but I prefer waiting for this bug to be fixed. Thanks for the suggestion. |
This commit is a first attempt at getting the stack.yaml actually
working and building successfully with nix.
Currently this is hard-coded to use the non-cuda CPU build, but this
should be changed in the future.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch get-stack.yaml-working
# Changes to be committed:
# new file: nix/stack-shell.nix
# modified: stack.yaml
#
# Untracked files:
# shell-hoogle.nix
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
diff --git a/nix/stack-shell.nix b/nix/stack-shell.nix
new file mode 100644
index 00000000..72fe20d5
--- /dev/null
+++ b/nix/stack-shell.nix
@@ -0,0 +1,56 @@
+
+let
+ sources = import ./sources.nix;
+
+ haskellNix = import sources.haskell-nix {
+ sourcesOverride = sources;
+ };
+
+ haskellNixOverlays = pkgsNew: pkgsOld: {
+ haskell-nix = pkgsOld.haskell-nix // { hackageSrc = sources.hackage-nix; };
+ };
+
+ nixpkgsSrc = haskellNix.sources.nixpkgs-2003;
+
+ libtorchSrc = pkgs:
+ pkgs.callPackage "${sources.pytorch-world}/libtorch/release.nix" { };
+
+ libtorchOverlayCpu = pkgsNew: pkgsOld:
+ let
+ libtorch = (libtorchSrc pkgsOld).libtorch_cpu;
+ in {
+ c10 = libtorch;
+ torch = libtorch;
+ torch_cpu = libtorch;
+ };
+
+ pkgs =
+ import
+ nixpkgsSrc
+ (haskellNix.nixpkgsArgs // {
+ overlays = haskellNix.overlays ++ [ haskellNixOverlays libtorchOverlayCpu ];
+ });
+in
+
+{ withHoogle ? false
+}@Args:
+
+pkgs.haskell.lib.buildStackProject {
+ name = "stack-build-hasktorch";
+ ghc = pkgs.haskell.compiler.ghc883;
+ extraArgs = [
+ "--extra-include-dirs=${pkgs.torch}/include/torch/csrc/api/include"
+ ];
+ buildInputs = with pkgs; [
+ # caffe2
+ # eigen
+ # git
+ # glog
+ # google-gflags
+ # libffi
+ # protobuf
+ torch
+ zlib
+ ];
+ inherit withHoogle;
+}
diff --git a/stack.yaml b/stack.yaml
index 62fc111b..23b680d1 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -8,14 +8,6 @@ packages:
- examples
- experimental
-extra-include-dirs:
- - deps/libtorch/include/torch/csrc/api/include
- - deps/libtorch/include
-
-extra-lib-dirs:
- - deps/libtorch/lib
- - deps/mklml/lib
-
# see commercialhaskell/stack#4073
# with-gcc: /usr/local/bin/gcc-7
@@ -34,6 +26,6 @@ extra-deps:
- streaming-attoparsec-1.0.0.1@sha256:fe9b878072423d3f075534fe8af24722d9ded1a1129e9a6ed5b71c4a29681b39,1146
- streaming-cassava-0.1.0.1@sha256:2d1dfeb09af62009e88311fe92f44d06dafb5cdd38879b437ea6adb3bc40acfe,1739
-
nix:
- packages: [zlib.dev, zlib.out]
+ enable: true
+ shell-file: nix/stack-shell.nix
|
Hi! Heads up about haskell/cabal#7874, which is a PR solving this ticket that @jberryman has kindly just rebased and we are desperate to merge before it bitrots. We need to add a small test for that or at least test the branch on the examples you have. Please help! [edit: was wrong cabal ticket number] |
|
Please kindly also have a look (and review) at #7900, which provides a test and discusses its result. Last chance to provide feedback before we merge. Thank you! |
|
@Mikolaj Hello, I am afraid I won't have the time to test the fix. If someone has time to do it, they can follow the steps in the description to verify that the issue is fixed. |
|
@OlivierSohn: understood. Thank you for reporting. Should we close this issue (and re-open if anything is amiss)? @jberryman: thank you for haskell/cabal#7900, which is now merged, which ends the saga! Please, everybody, test the fix and report if anything is still missing. The feature should be released in cabal 3.8 (no release date planned yet). |
|
I am closing this issue given the passage of time and the comment above about the resolution of the upstream issue. |
The context is that I need to use a gcc supporting the C++17 standard.
When passing
--with-gcc=c:\msys64\MINGW32\bin\gccto stack invocation, I was expecting that ghc would use the given gcc to build my code, but it ignores it.Steps to reproduce
Using a
projectWithCSources.cabal(I use this one) where during c preprocessor phase, we print the compiler version like so:Given a more recent
gcc(located at<path-to-new-gcc>) than the one used when doingstack exec -- gcc --versionstack exec -- gcc --versionThis gives us
version1stack --with-gcc=<path-to-new-gcc> buildthis gives us
version2, printed during the c-preprocessor phaseNote that this is a simplified version of this Appveyor script
The bug happens for ghc8.2.2 (resolver
lts-11.9) and ghc8.4.3 (resolvernightly-2018-06-07)Expected
version2 > version1
Actual
version2 == version1
The verbose output is available here (line 2030 is the command to build the project, line 2046 shows the gcc version used by ghc to compile the c sources)
Stack version
Method of installation
The text was updated successfully, but these errors were encountered: