New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't setup ghcjs with stack: ghcjs version could not be determined. #1496

Closed
gromakovsky opened this Issue Dec 11, 2015 · 67 comments

Comments

Projects
None yet
@gromakovsky

gromakovsky commented Dec 11, 2015

I'm trying to use stack with ghcjs. I've created dummy project (stack.yaml file is in gist, other files are hardly relevant). After that I run stack setup and get this error:

setup: The program 'ghcjs' version >=0.1 is required but the version of
/home/gromak/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151029_ghc-7.10.2/src/.stack-work/install/x86_64-linux/lts-3.6/7.10.2/bin/ghcjs could not be determined.

Even if I do mv ~/.stack ~/.stack.bk; mv ~/.cabal ~/.cabal.bk I get the same error. You can take a look at the complete output of stack setup in gist. By the way, I'm running on Archlinux.

Here is gist: https://gist.github.com/gromakovsky/660735e773213b989d44

Some information about versions:

$ stack --version
Version 0.1.10.0, Git revision a25892f (2778 commits) x86_64
$ cabal --version
cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.2
$ /home/gromak/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151029_ghc-7.10.2/src/.stack-work/install/x86_64-linux/lts-3.6/7.10.2/bin/ghcjs --version
The Glorious Glasgow Haskell Compilation System for JavaScript, version 0.2.0.20151029 (GHC 7.10.2)

Please ask me to provide more information about my environment if you need it.

@tolysz

This comment has been minimized.

Show comment
Hide comment
@tolysz

tolysz Dec 11, 2015

Collaborator

Is the project you are trying to build hosted somewhere?

PATH=`stack path --bin-path  --stack-yaml $HOME/.stack/global-project/stack.yaml --resolver lts-3.17 2>/dev/null`:$PATH stack setup

I only see you are using global ghc could you try with the above? (and maybe install hscolour )

I am using my own version with patched aeson ( https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml )

Collaborator

tolysz commented Dec 11, 2015

Is the project you are trying to build hosted somewhere?

PATH=`stack path --bin-path  --stack-yaml $HOME/.stack/global-project/stack.yaml --resolver lts-3.17 2>/dev/null`:$PATH stack setup

I only see you are using global ghc could you try with the above? (and maybe install hscolour )

I am using my own version with patched aeson ( https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml )

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Dec 12, 2015

Collaborator

aupiff is also getting this, as mentioned in the #ghcjs channel. He's using the same version, ghcjs-0.2.0.20151029, so I suspect this is an issue with that particular sdist or ghcjs version.

I haven't seen such issues with the old-base sdist or fizruk's improved-base sdist. Can you please post up your particular setup-info?

Collaborator

mgsloan commented Dec 12, 2015

aupiff is also getting this, as mentioned in the #ghcjs channel. He's using the same version, ghcjs-0.2.0.20151029, so I suspect this is an issue with that particular sdist or ghcjs version.

I haven't seen such issues with the old-base sdist or fizruk's improved-base sdist. Can you please post up your particular setup-info?

@gromakovsky

This comment has been minimized.

Show comment
Hide comment
@gromakovsky

gromakovsky Dec 12, 2015

Is the project you are trying to build hosted somewhere?

It's our own project. We've just started using ghcjs, my colleagues have managed to setup it, but I get this error. Looks like we have same versions of everything (i. e. stack, cabal, ghc, ghcjs), but for some strange reason this error occurs only on my machine.

I tried using stack setup with extended PATH, but result is the same. I also tried this stack.yaml: https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml but once again result is the same.

I suspect this is an issue with that particular sdist or ghcjs version

I tried running stack setup --compiler ghcjs-0.1.0.20150924_ghc-7.10.2, but it didn't help. Also, as I already told, I tried using stack.yaml referenced by @tolysz, it didn't help too. As well as this configuration:

compiler: ghcjs-0.2.0.20151001_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20151001_ghc-7.10.2:
        url: "https://github.com/fizruk/ghcjs/releases/download/v0.2.0.20151001/ghcjs-0.2.0.20151001.tar.gz"

Can you please post up your particular setup-info?

Sorry, I don't know what is setup-info. Can you explain please?

gromakovsky commented Dec 12, 2015

Is the project you are trying to build hosted somewhere?

It's our own project. We've just started using ghcjs, my colleagues have managed to setup it, but I get this error. Looks like we have same versions of everything (i. e. stack, cabal, ghc, ghcjs), but for some strange reason this error occurs only on my machine.

I tried using stack setup with extended PATH, but result is the same. I also tried this stack.yaml: https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml but once again result is the same.

I suspect this is an issue with that particular sdist or ghcjs version

I tried running stack setup --compiler ghcjs-0.1.0.20150924_ghc-7.10.2, but it didn't help. Also, as I already told, I tried using stack.yaml referenced by @tolysz, it didn't help too. As well as this configuration:

compiler: ghcjs-0.2.0.20151001_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20151001_ghc-7.10.2:
        url: "https://github.com/fizruk/ghcjs/releases/download/v0.2.0.20151001/ghcjs-0.2.0.20151001.tar.gz"

Can you please post up your particular setup-info?

Sorry, I don't know what is setup-info. Can you explain please?

@gromakovsky

This comment has been minimized.

Show comment
Hide comment
@gromakovsky

gromakovsky Dec 12, 2015

Sorry, I don't know what is setup-info. Can you explain please?

Ah, looks like it's from stack.yaml. It is in the gist: https://gist.github.com/gromakovsky/660735e773213b989d44#file-stack-yaml

Actually, as I said, the same error occurs with other configurations too (e. g. this: https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml)

gromakovsky commented Dec 12, 2015

Sorry, I don't know what is setup-info. Can you explain please?

Ah, looks like it's from stack.yaml. It is in the gist: https://gist.github.com/gromakovsky/660735e773213b989d44#file-stack-yaml

Actually, as I said, the same error occurs with other configurations too (e. g. this: https://github.com/tolysz/video/blob/ghcjs/client/stack.yaml)

@akegalj

This comment has been minimized.

Show comment
Hide comment
@akegalj

akegalj Dec 12, 2015

(I have deleted something that I find irrelevant now)

EDIT: looks like I am getting this error always now (when I am running only one stack build, even with clean ghcjs boot and clean stack setup). It seems that error started appearing when I have done full update of my system. Here is the update info: https://gist.github.com/akegalj/652a4b771949148d6042 . Somehow relevant were:

[2015-12-11 15:20] [ALPM] upgraded ghc (7.10.2-1 -> 7.10.3-1)
[2015-12-11 15:20] [ALPM-SCRIPTLET] ==> All cabalized packages need to be reinstalled now.
[2015-12-11 15:20] [ALPM-SCRIPTLET] ==> See /usr/share/haskell/ for a tentative list of affected packages.
[2015-12-11 15:21] [ALPM] upgraded happy (1.19.5-3 -> 1.19.5-4)
[2015-12-11 15:19] [ALPM] upgraded alex (3.1.4-6 -> 3.1.4-7)

but there were upgrades of other packages globally installed (like haskell-data-default-instances-base and others, see gist). I don't know could this be the reason of breakage of stack ghcjs install?

EDIT EDIT:
It looks like there is a high chance that stack ghcjs breakage came from this upgrade. When I run stack build I am getting errors:

   Configuring data-default-instances-base-0.0.1...
    setup-Simple-Cabal-1.22.4.0-ghcjs-0.2.0.20151029_ghc-7.10.2: The program
    'ghcjs' version >=0.1 is required but the version of
    /home/akegalj/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151029_ghc-7.10.2/bin/ghcjs
    could not be determined.

and same errors for data-default-instances-dlist-0.0.1, random-1.1, ref-tf-0.4, ... which highly correlates to haskell-* packages from upgrade gist https://gist.github.com/akegalj/652a4b771949148d6042 .

akegalj commented Dec 12, 2015

(I have deleted something that I find irrelevant now)

EDIT: looks like I am getting this error always now (when I am running only one stack build, even with clean ghcjs boot and clean stack setup). It seems that error started appearing when I have done full update of my system. Here is the update info: https://gist.github.com/akegalj/652a4b771949148d6042 . Somehow relevant were:

[2015-12-11 15:20] [ALPM] upgraded ghc (7.10.2-1 -> 7.10.3-1)
[2015-12-11 15:20] [ALPM-SCRIPTLET] ==> All cabalized packages need to be reinstalled now.
[2015-12-11 15:20] [ALPM-SCRIPTLET] ==> See /usr/share/haskell/ for a tentative list of affected packages.
[2015-12-11 15:21] [ALPM] upgraded happy (1.19.5-3 -> 1.19.5-4)
[2015-12-11 15:19] [ALPM] upgraded alex (3.1.4-6 -> 3.1.4-7)

but there were upgrades of other packages globally installed (like haskell-data-default-instances-base and others, see gist). I don't know could this be the reason of breakage of stack ghcjs install?

EDIT EDIT:
It looks like there is a high chance that stack ghcjs breakage came from this upgrade. When I run stack build I am getting errors:

   Configuring data-default-instances-base-0.0.1...
    setup-Simple-Cabal-1.22.4.0-ghcjs-0.2.0.20151029_ghc-7.10.2: The program
    'ghcjs' version >=0.1 is required but the version of
    /home/akegalj/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151029_ghc-7.10.2/bin/ghcjs
    could not be determined.

and same errors for data-default-instances-dlist-0.0.1, random-1.1, ref-tf-0.4, ... which highly correlates to haskell-* packages from upgrade gist https://gist.github.com/akegalj/652a4b771949148d6042 .

@gromakovsky

This comment has been minimized.

Show comment
Hide comment
@gromakovsky

gromakovsky Dec 13, 2015

After full system update (including update of ghc, happy and alex) I still had the same error. Stack downloaded GHC 7.10.2 and installed it into it's own directory, because system-wide GHC upgraded to 7.10.3. Then I downgraded system-wide GHC to 7.10.2 and (magic!) stack setup finished successfully! However, if then I run stack build I get similar errors like those from @akegalj comment (i. e. ghcjs version could not be determined). If I run stack build multiple times it makes some progress, but after building some packages it stops making any progress (i. e. reports this error for every package).

Finally, I removed ~/.cabal, ~/.stack, ~/.ghcjs, ~/.ghc, .stack-work and ran stack setup once again with these versions of system-wide packages:

happy 1.19.5-4
alex 3.1.4-7
ghc 7.10.2-1

Surprisingly, stack setup failed again with the same error as at the first time. So for me it now looks like this error is nondeterministic. We (I and @akegalj) couldn't understand which versions of relevant software cause this error. Even if the same set of versions it may lead to different results. For example, if problem occurres during stack build step it may fail to build a package, but after a few more tries it suddenly succeeds. Very strange…

gromakovsky commented Dec 13, 2015

After full system update (including update of ghc, happy and alex) I still had the same error. Stack downloaded GHC 7.10.2 and installed it into it's own directory, because system-wide GHC upgraded to 7.10.3. Then I downgraded system-wide GHC to 7.10.2 and (magic!) stack setup finished successfully! However, if then I run stack build I get similar errors like those from @akegalj comment (i. e. ghcjs version could not be determined). If I run stack build multiple times it makes some progress, but after building some packages it stops making any progress (i. e. reports this error for every package).

Finally, I removed ~/.cabal, ~/.stack, ~/.ghcjs, ~/.ghc, .stack-work and ran stack setup once again with these versions of system-wide packages:

happy 1.19.5-4
alex 3.1.4-7
ghc 7.10.2-1

Surprisingly, stack setup failed again with the same error as at the first time. So for me it now looks like this error is nondeterministic. We (I and @akegalj) couldn't understand which versions of relevant software cause this error. Even if the same set of versions it may lead to different results. For example, if problem occurres during stack build step it may fail to build a package, but after a few more tries it suddenly succeeds. Very strange…

@eallik

This comment has been minimized.

Show comment
Hide comment
@eallik

eallik Dec 14, 2015

Contributor

I'm also experiencing this problem — I never used to have this problem some time ago; perhaps an update of stack to 0.1.10 caused it? (EDIT: nope, just downgraded and the problem's still there)

@gromakovsky I can confirm the errors are non-deterministic. I didn't try stack setup but stack build always errors out while building a different dependency.

Contributor

eallik commented Dec 14, 2015

I'm also experiencing this problem — I never used to have this problem some time ago; perhaps an update of stack to 0.1.10 caused it? (EDIT: nope, just downgraded and the problem's still there)

@gromakovsky I can confirm the errors are non-deterministic. I didn't try stack setup but stack build always errors out while building a different dependency.

@eallik

This comment has been minimized.

Show comment
Hide comment
@eallik

eallik Dec 14, 2015

Contributor

For the record, it's also happening with ghcjs-pkg: http://pastebin.com/raw.php?i=pNbrUhcE

Also, as you can see, I tried with -j0 to rule out any race conditions, but the result appears to be the same.

Contributor

eallik commented Dec 14, 2015

For the record, it's also happening with ghcjs-pkg: http://pastebin.com/raw.php?i=pNbrUhcE

Also, as you can see, I tried with -j0 to rule out any race conditions, but the result appears to be the same.

@akegalj

This comment has been minimized.

Show comment
Hide comment
@akegalj

akegalj Dec 14, 2015

Interesting though, running repeatedly stack build will eventually build the whole thing. So as a workaround you can do:

until stack build; do echo "Try again!"; done

This successfully builds the whole project, despite bunch of errors/retries.

NOTE: you should modify this command to repeat only on this type of error (ie grep-ing 'ghcjs' version >=0.1 is required) and to fail otherwise.

akegalj commented Dec 14, 2015

Interesting though, running repeatedly stack build will eventually build the whole thing. So as a workaround you can do:

until stack build; do echo "Try again!"; done

This successfully builds the whole project, despite bunch of errors/retries.

NOTE: you should modify this command to repeat only on this type of error (ie grep-ing 'ghcjs' version >=0.1 is required) and to fail otherwise.

@eallik

This comment has been minimized.

Show comment
Hide comment
@eallik

eallik Dec 14, 2015

Contributor

Actually this morning I've gotten to a point where it's always failing immediately and always at the same package (http-conduit but I doubt that package has anything to do with this).

P.S. But then again, the until trick did the job as you said.

Contributor

eallik commented Dec 14, 2015

Actually this morning I've gotten to a point where it's always failing immediately and always at the same package (http-conduit but I doubt that package has anything to do with this).

P.S. But then again, the until trick did the job as you said.

@eallik

This comment has been minimized.

Show comment
Hide comment
@eallik

eallik Dec 14, 2015

Contributor

Furthermore, the error generally seems to occur faster with parallelism — when I tried with -j1 it failed later and with just one package erroring out, while normally I was getting errors from multiple packages during a single run of stack build.

Contributor

eallik commented Dec 14, 2015

Furthermore, the error generally seems to occur faster with parallelism — when I tried with -j1 it failed later and with just one package erroring out, while normally I was getting errors from multiple packages during a single run of stack build.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Dec 20, 2015

Collaborator

Note that these error messages are coming from the Cabal library - and something very similar is happening with cabal-install ghcjs/ghcjs#451 .

I'll leave this open for now, though. Probably the place to fix this is ghcjs itself or Cabal, but first we've got to figure out what's happening.

Collaborator

mgsloan commented Dec 20, 2015

Note that these error messages are coming from the Cabal library - and something very similar is happening with cabal-install ghcjs/ghcjs#451 .

I'll leave this open for now, though. Probably the place to fix this is ghcjs itself or Cabal, but first we've got to figure out what's happening.

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Dec 23, 2015

Contributor

I have this problem too on Arch Linux - both on my everyday machine and in a clean docker build with Arch, GHCJS boot (reliably) fails. I'm trying exactly the same GHCJS/GHC versions as @gromakovsky, and log is exactly the same too. Interestingly, in a clean Ubuntu docker container (using the same procedure, except for installing necessary packages using apt-get instead of pacman) it boots successfully. So looks for me as a difference in environment coming from different OS. Didn't have time to look further yet.

Contributor

quyse commented Dec 23, 2015

I have this problem too on Arch Linux - both on my everyday machine and in a clean docker build with Arch, GHCJS boot (reliably) fails. I'm trying exactly the same GHCJS/GHC versions as @gromakovsky, and log is exactly the same too. Interestingly, in a clean Ubuntu docker container (using the same procedure, except for installing necessary packages using apt-get instead of pacman) it boots successfully. So looks for me as a difference in environment coming from different OS. Didn't have time to look further yet.

@yamafaktory

This comment has been minimized.

Show comment
Hide comment
@yamafaktory

yamafaktory Dec 27, 2015

I am facing the same issue on Arch too:

/home/davy/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151001_ghc-7.10.2/src/.stack-work/install/x86_64-linux/lts-3.6/7.10.2/bin/ghcjs
could not be determined.                      
cabal: Error: some packages failed to install:
Cabal-1.22.4.0 failed during the configure step. The exception was:
ExitFailure 1   
stack --version
Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64

yamafaktory commented Dec 27, 2015

I am facing the same issue on Arch too:

/home/davy/.stack/programs/x86_64-linux/ghcjs-0.2.0.20151001_ghc-7.10.2/src/.stack-work/install/x86_64-linux/lts-3.6/7.10.2/bin/ghcjs
could not be determined.                      
cabal: Error: some packages failed to install:
Cabal-1.22.4.0 failed during the configure step. The exception was:
ExitFailure 1   
stack --version
Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64
@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Dec 30, 2015

Contributor

I have the same issue on macos, stack from git 1.0.1.
the until stack build; do echo "Try again!"; done does the trick, though it takes forever

Contributor

nrolland commented Dec 30, 2015

I have the same issue on macos, stack from git 1.0.1.
the until stack build; do echo "Try again!"; done does the trick, though it takes forever

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jan 7, 2016

Member

Same issue on Mac OS X and very recent stack (Version 1.0.1, Git revision d0d6819 x86_64).

Member

3noch commented Jan 7, 2016

Same issue on Mac OS X and very recent stack (Version 1.0.1, Git revision d0d6819 x86_64).

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Jan 9, 2016

Contributor

@3noch i don't think it's related to stack, other people had it while using cabal the binary. however that seems to be something newish. I wonder where it could possibly come from.

Contributor

nrolland commented Jan 9, 2016

@3noch i don't think it's related to stack, other people had it while using cabal the binary. however that seems to be something newish. I wonder where it could possibly come from.

@hanshoglund

This comment has been minimized.

Show comment
Hide comment
@hanshoglund

hanshoglund Jan 9, 2016

@mgsloan and Stack devs: Given the frequency of this issue, is there any effort to co-ordinate a fix with the GHCJS/Cabal team?

hanshoglund commented Jan 9, 2016

@mgsloan and Stack devs: Given the frequency of this issue, is there any effort to co-ordinate a fix with the GHCJS/Cabal team?

@tolysz

This comment has been minimized.

Show comment
Hide comment
@tolysz

tolysz Jan 9, 2016

Collaborator

Could anyone give a Docker example when it fails?

Collaborator

tolysz commented Jan 9, 2016

Could anyone give a Docker example when it fails?

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Jan 9, 2016

Contributor

@tolysz Here is my dockerfile for booting GHCJS on Arch Linux (that's what I'm struggling with): https://gist.github.com/quyse/4441543374b3102f7fd5
Fails with the same error.

Contributor

quyse commented Jan 9, 2016

@tolysz Here is my dockerfile for booting GHCJS on Arch Linux (that's what I'm struggling with): https://gist.github.com/quyse/4441543374b3102f7fd5
Fails with the same error.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 9, 2016

Collaborator

I've tried building some larger projects (ghcjs-improved-base-2 branch of reflex-dom) along with ghcjs-0.2.0.20151230.3_ghc-7.10.2 , and encountered no problems.

Since I can't reproduce the issue, I can't look into fixing it (and the issue doesn't directly affect me). It would be very helpful if people had public projects that reproduce the issue, and better yet, as @tolysz mentions, a reproduction in a docker image would be great.

I'm 90% sure the root cause of this is in Cabal or GHCJS. Leaving the issue open since this seems to be the main place to collect info about the problem.

Collaborator

mgsloan commented Jan 9, 2016

I've tried building some larger projects (ghcjs-improved-base-2 branch of reflex-dom) along with ghcjs-0.2.0.20151230.3_ghc-7.10.2 , and encountered no problems.

Since I can't reproduce the issue, I can't look into fixing it (and the issue doesn't directly affect me). It would be very helpful if people had public projects that reproduce the issue, and better yet, as @tolysz mentions, a reproduction in a docker image would be great.

I'm 90% sure the root cause of this is in Cabal or GHCJS. Leaving the issue open since this seems to be the main place to collect info about the problem.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 9, 2016

Collaborator

@quyse Thanks, I'll give it a try! What project fails to build? It'd also be handy if I could just load up an image from dockerhub instead of a dockerfile, but no worries, I'll just build it..

Collaborator

mgsloan commented Jan 9, 2016

@quyse Thanks, I'll give it a try! What project fails to build? It'd also be handy if I could just load up an image from dockerhub instead of a dockerfile, but no worries, I'll just build it..

@tolysz

This comment has been minimized.

Show comment
Hide comment
@tolysz

tolysz Jan 9, 2016

Collaborator

I think the ghcjs installation fails

Collaborator

tolysz commented Jan 9, 2016

I think the ghcjs installation fails

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 9, 2016

Collaborator

Ah, I see, so that's why it isn't possible to upload a docker image, if the dockerfile fails.

Still building, it just finished booting base.

Collaborator

mgsloan commented Jan 9, 2016

Ah, I see, so that's why it isn't possible to upload a docker image, if the dockerfile fails.

Still building, it just finished booting base.

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Jan 9, 2016

Contributor

@mgsloan Yes, booting GHCJS is the thing which fails, and as it's the most time-consuming part, I didn't bother to upload last successful stage to dockerhub, sorry. I also have low upload speeds :( As I said, the build log looks exactly the same as in the @gromakovsky gist from the first message https://gist.github.com/gromakovsky/660735e773213b989d44

Contributor

quyse commented Jan 9, 2016

@mgsloan Yes, booting GHCJS is the thing which fails, and as it's the most time-consuming part, I didn't bother to upload last successful stage to dockerhub, sorry. I also have low upload speeds :( As I said, the build log looks exactly the same as in the @gromakovsky gist from the first message https://gist.github.com/gromakovsky/660735e773213b989d44

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 9, 2016

Collaborator

Ok, I can reproduce. The current theory I'm considering is that it's a matter of node version. I have v0.10.37, whereas your docker has v5.4.0 (for some reason node jumped from v0 to v4?!). This is particularly supported by a recent comment where there are two machines with similar setup, but only one of them has the issue.

I knew I'd regret not having stack control the node version / auto install it, but what version do we pick??

Currently testing this theory out by updating my local version of node.

Collaborator

mgsloan commented Jan 9, 2016

Ok, I can reproduce. The current theory I'm considering is that it's a matter of node version. I have v0.10.37, whereas your docker has v5.4.0 (for some reason node jumped from v0 to v4?!). This is particularly supported by a recent comment where there are two machines with similar setup, but only one of them has the issue.

I knew I'd regret not having stack control the node version / auto install it, but what version do we pick??

Currently testing this theory out by updating my local version of node.

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 9, 2016

Collaborator

Yup, this is due to node version. After updating from node v0.10.37 to node v5.4.0, I can now reproduce the issue locally.

Closing as an upstream issue. I've opened #1632 to track having stack setup control and install node version.

Collaborator

mgsloan commented Jan 9, 2016

Yup, this is due to node version. After updating from node v0.10.37 to node v5.4.0, I can now reproduce the issue locally.

Closing as an upstream issue. I've opened #1632 to track having stack setup control and install node version.

@dysinger

This comment has been minimized.

Show comment
Hide comment
@dysinger

dysinger Jan 25, 2016

Contributor

I tried the latest Node 5.x from nodesource (without knowing about this bug). I hit this issue exactly. I then backed up to Node 4.x & got the same error. I then ditched nodesource in favor of the Ubuntu 15.10 package of nodejs (0.10.25) which worked fine. Neither 4.x nor 5.x worked. I did not clean out ~/.ghcjs in between tries. This may be part of the problem.

Contributor

dysinger commented Jan 25, 2016

I tried the latest Node 5.x from nodesource (without knowing about this bug). I hit this issue exactly. I then backed up to Node 4.x & got the same error. I then ditched nodesource in favor of the Ubuntu 15.10 package of nodejs (0.10.25) which worked fine. Neither 4.x nor 5.x worked. I did not clean out ~/.ghcjs in between tries. This may be part of the problem.

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jan 25, 2016

Member

I just tried 5.5 and hit the problem (I cleaned out everything first too).

Member

3noch commented Jan 25, 2016

I just tried 5.5 and hit the problem (I cleaned out everything first too).

@dysinger

This comment has been minimized.

Show comment
Hide comment
@dysinger

dysinger Jan 25, 2016

Contributor

I just tested again. System: Ubuntu 15.10 x86_64 - stack 1.0.2

Totally clean box. Making sure to remove ~/.stack ~/.ghc ~/.cabal ~/.ghcjs every run.

nodejs-5.x (latest) from nodesource : Fail
nodejs-4.x (latest) from nodesource : Fail
nodejs-0.10.40 (binary x86_64 download) : Success
nodejs-0.10.25 (ubuntu package) : Success

Contributor

dysinger commented Jan 25, 2016

I just tested again. System: Ubuntu 15.10 x86_64 - stack 1.0.2

Totally clean box. Making sure to remove ~/.stack ~/.ghc ~/.cabal ~/.ghcjs every run.

nodejs-5.x (latest) from nodesource : Fail
nodejs-4.x (latest) from nodesource : Fail
nodejs-0.10.40 (binary x86_64 download) : Success
nodejs-0.10.25 (ubuntu package) : Success

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 25, 2016

Collaborator

Strange! It boots for me with node v4.2.4, stack from yesterday, and ghcjs-0.2.0.20151230

Collaborator

mgsloan commented Jan 25, 2016

Strange! It boots for me with node v4.2.4, stack from yesterday, and ghcjs-0.2.0.20151230

@dysinger

This comment has been minimized.

Show comment
Hide comment
@dysinger

dysinger Jan 25, 2016

Contributor

ghcjs-0.2.0.20151230 was the version I was trying every time

Contributor

dysinger commented Jan 25, 2016

ghcjs-0.2.0.20151230 was the version I was trying every time

@drwebb

This comment has been minimized.

Show comment
Hide comment
@drwebb

drwebb Jan 26, 2016

Contributor

On Arch upgrading to node v5.5.0 helped, I was able to run setup and build a project that wasn't building as I was trying to trigger the bug with v5.2.0. I would still get the error until I cleared out ~/.ghcjs. I think it was around an upgrade in Dec 2015 that I noticed the issue. I hope it actually stays resolved.

Edit: whoops triple posted!

Contributor

drwebb commented Jan 26, 2016

On Arch upgrading to node v5.5.0 helped, I was able to run setup and build a project that wasn't building as I was trying to trigger the bug with v5.2.0. I would still get the error until I cleared out ~/.ghcjs. I think it was around an upgrade in Dec 2015 that I noticed the issue. I hope it actually stays resolved.

Edit: whoops triple posted!

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Jan 26, 2016

Member

Perhaps it's OS X related? I'm on OS X.

Member

3noch commented Jan 26, 2016

Perhaps it's OS X related? I'm on OS X.

@geraldus

This comment has been minimized.

Show comment
Hide comment
@geraldus

geraldus Jan 26, 2016

@3noch I'm on OS X too.

geraldus commented Jan 26, 2016

@3noch I'm on OS X too.

@tgerder

This comment has been minimized.

Show comment
Hide comment
@tgerder

tgerder Jan 26, 2016

I have the same issue on Linux:
installation script: https://gist.github.com/tgerder/1c157372316446750c43
result: https://gist.github.com/tgerder/7187339e78b9e7b3a5b7
installation results are similar to @gromakovsky 's

tgerder commented Jan 26, 2016

I have the same issue on Linux:
installation script: https://gist.github.com/tgerder/1c157372316446750c43
result: https://gist.github.com/tgerder/7187339e78b9e7b3a5b7
installation results are similar to @gromakovsky 's

@dysinger

This comment has been minimized.

Show comment
Hide comment
@dysinger

dysinger Jan 26, 2016

Contributor

Why would node 5.5 work on Arch & fail on Ubuntu? I'm puzzled that people are saying the released 4.x or 5.x of node works for them. I watched it fail repeatedly even with a totally clean & stripped $HOME

Contributor

dysinger commented Jan 26, 2016

Why would node 5.5 work on Arch & fail on Ubuntu? I'm puzzled that people are saying the released 4.x or 5.x of node works for them. I watched it fail repeatedly even with a totally clean & stripped $HOME

@drwebb

This comment has been minimized.

Show comment
Hide comment
@drwebb

drwebb Jan 26, 2016

Contributor

Strange, I ran a successful stack setup --docker with the following Dockerfile (fpco/stack-build base):

FROM fpco/stack-build:lts-3.20

RUN git clone https://github.com/creationix/nvm.git /opt/nvm

RUN mkdir /usr/local/nvm
ENV NVM_DIR /usr/local/nvm
RUN /bin/bash -c "source /opt/nvm/nvm.sh && nvm install 5.5.0"

stack.yaml:

flags: {}
extra-package-dbs: []
packages:
- '.'

resolver: lts-3.20
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
setup-info:
 ghcjs:
  source:
   ghcjs-0.2.0.20151230.3_ghc-7.10.2:
    url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"

docker:
    enable: false
    image: "stack-build-node_v5.5.0"
    env:
        - "PATH=/usr/local/nvm/versions/node/v5.5.0/bin:/opt/host/bin:/opt/stackage/lts-3/extra/bin:/opt/stackage/lts-3/ghc/bin:/opt/stackage/lts-3/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Contributor

drwebb commented Jan 26, 2016

Strange, I ran a successful stack setup --docker with the following Dockerfile (fpco/stack-build base):

FROM fpco/stack-build:lts-3.20

RUN git clone https://github.com/creationix/nvm.git /opt/nvm

RUN mkdir /usr/local/nvm
ENV NVM_DIR /usr/local/nvm
RUN /bin/bash -c "source /opt/nvm/nvm.sh && nvm install 5.5.0"

stack.yaml:

flags: {}
extra-package-dbs: []
packages:
- '.'

resolver: lts-3.20
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
setup-info:
 ghcjs:
  source:
   ghcjs-0.2.0.20151230.3_ghc-7.10.2:
    url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"

docker:
    enable: false
    image: "stack-build-node_v5.5.0"
    env:
        - "PATH=/usr/local/nvm/versions/node/v5.5.0/bin:/opt/host/bin:/opt/stackage/lts-3/extra/bin:/opt/stackage/lts-3/ghc/bin:/opt/stackage/lts-3/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
@alios

This comment has been minimized.

Show comment
Hide comment
@alios

alios Jan 28, 2016

Ok for me on ArchLinux (x64) - it was definitly the nodejs 5.5

  • deeinstalled it (yaourt -R nodejs npm)
  • installed nodejs-0.12 from AUR (yaourt -S nodejs-0.12 npm)
  • git a free ghcjs-boot --dev
  • did run smooth

now compiling of packets and everything else seems to work again.

alios commented Jan 28, 2016

Ok for me on ArchLinux (x64) - it was definitly the nodejs 5.5

  • deeinstalled it (yaourt -R nodejs npm)
  • installed nodejs-0.12 from AUR (yaourt -S nodejs-0.12 npm)
  • git a free ghcjs-boot --dev
  • did run smooth

now compiling of packets and everything else seems to work again.

@drwebb

This comment has been minimized.

Show comment
Hide comment
@drwebb

drwebb Feb 2, 2016

Contributor

I have to report back that my nodejs 5.5 installation encountered the bug some days after the initial stack setup worked. I'm living with it at the moment, as repeated attempts to build eventually compile.

Contributor

drwebb commented Feb 2, 2016

I have to report back that my nodejs 5.5 installation encountered the bug some days after the initial stack setup worked. I'm living with it at the moment, as repeated attempts to build eventually compile.

@dmjio

This comment has been minimized.

Show comment
Hide comment
@dmjio

dmjio Feb 7, 2016

Same issue on OSX, node v5.5.0, repeated attempts do not eventually compile.

dmjio commented Feb 7, 2016

Same issue on OSX, node v5.5.0, repeated attempts do not eventually compile.

@dmjio

This comment has been minimized.

Show comment
Hide comment
@dmjio

dmjio Feb 7, 2016

On OSX rolling node back brew uninstall node and installing v0.10.41 (brew install homebrew/versions/node010) seems to be successful.

dmjio commented Feb 7, 2016

On OSX rolling node back brew uninstall node and installing v0.10.41 (brew install homebrew/versions/node010) seems to be successful.

@EugeneN

This comment has been minimized.

Show comment
Hide comment
@EugeneN

EugeneN Feb 15, 2016

Looks like the issue is indeed because of bad node version. ghcjs-boot caches $PATH and path to node executable in semi-binary per-package config files when being installed initially (eg, ~/.ghcjs/x86_64-darwin-0.2.0.20151029-7.10.2/ghcjs/ghcjs-boot/boot/vector/dist/setup-config)

Should one have a bad (for ghcjs) node version at the moment of installation it will be remembered and used later, even when one reinstalls node (into some other filesystem path, leaving old one intact (some package managers do this)).

There is also a text file ~/.ghcjs/x86_64-darwin-0.2.0.20151029-7.10.2/ghcjs/node with the content like this: /path/to/bin/node, pointing to the wrong node version. But fixing this file to the correct path to the right node version seems to have no effect.

The solution for me was to create a symlink with a name of the wrong node version pointing to a dir with right node version. Reinstalling ghcjs-boot etc would probably have effect too, should you have few spare hours :-)

Interestingly enough, with this kind of setup stack build worked fine for me, but stack haddock did not, showing "Can't setup ghcjs with stack: ghcjs version could not be determined." error message.

Actually stack build has been producing the same error too, until changing $PATH to point to the right node version (v0.10.x btw). Looks like it respects env variables, while stack haddock uses some cached values.

Hope this will help.

EugeneN commented Feb 15, 2016

Looks like the issue is indeed because of bad node version. ghcjs-boot caches $PATH and path to node executable in semi-binary per-package config files when being installed initially (eg, ~/.ghcjs/x86_64-darwin-0.2.0.20151029-7.10.2/ghcjs/ghcjs-boot/boot/vector/dist/setup-config)

Should one have a bad (for ghcjs) node version at the moment of installation it will be remembered and used later, even when one reinstalls node (into some other filesystem path, leaving old one intact (some package managers do this)).

There is also a text file ~/.ghcjs/x86_64-darwin-0.2.0.20151029-7.10.2/ghcjs/node with the content like this: /path/to/bin/node, pointing to the wrong node version. But fixing this file to the correct path to the right node version seems to have no effect.

The solution for me was to create a symlink with a name of the wrong node version pointing to a dir with right node version. Reinstalling ghcjs-boot etc would probably have effect too, should you have few spare hours :-)

Interestingly enough, with this kind of setup stack build worked fine for me, but stack haddock did not, showing "Can't setup ghcjs with stack: ghcjs version could not be determined." error message.

Actually stack build has been producing the same error too, until changing $PATH to point to the right node version (v0.10.x btw). Looks like it respects env variables, while stack haddock uses some cached values.

Hope this will help.

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Mar 15, 2016

Contributor

is there a definitive procedure for getting rid of this problem ?

Can we assert that's not linked to a particular version but to a change in version ?

Contributor

nrolland commented Mar 15, 2016

is there a definitive procedure for getting rid of this problem ?

Can we assert that's not linked to a particular version but to a change in version ?

@EugeneN

This comment has been minimized.

Show comment
Hide comment
@EugeneN

EugeneN Mar 15, 2016

I believe something important for ghcjs broke in nodejs after some change in nodejs in some version. I'm not sure which version exactly. nodejs v0.10.47 works for sure, node v5.* doesn't.

EugeneN commented Mar 15, 2016

I believe something important for ghcjs broke in nodejs after some change in nodejs in some version. I'm not sure which version exactly. nodejs v0.10.47 works for sure, node v5.* doesn't.

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Mar 15, 2016

Contributor

GHCJS works for me currently with latest official nodejs-5.8.0 package on Arch Linux. I believe the problem in node has been fixed since node version 5.7.0 or so.

Contributor

quyse commented Mar 15, 2016

GHCJS works for me currently with latest official nodejs-5.8.0 package on Arch Linux. I believe the problem in node has been fixed since node version 5.7.0 or so.

@EugeneN

This comment has been minimized.

Show comment
Hide comment
@EugeneN

EugeneN Mar 15, 2016

wow that would be cool, I will try to reproduce :-)

EugeneN commented Mar 15, 2016

wow that would be cool, I will try to reproduce :-)

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 15, 2016

Member

Actually GHCJS fixed this issue, as long as you grab a recent build (last couple weeks).

Member

3noch commented Mar 15, 2016

Actually GHCJS fixed this issue, as long as you grab a recent build (last couple weeks).

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Mar 15, 2016

Contributor

@3noch I still use GHCJS from here https://github.com/nrolland/ghcjs/releases/tag/v0.2.0.20151029 which is several months old, so unless GHCJS has downloaded some freshly fixed code during boot process, I guess the fix is in node actually. However I would greatly appreciate some short wrap-up on the issue from someone who knows more what was going on.

Contributor

quyse commented Mar 15, 2016

@3noch I still use GHCJS from here https://github.com/nrolland/ghcjs/releases/tag/v0.2.0.20151029 which is several months old, so unless GHCJS has downloaded some freshly fixed code during boot process, I guess the fix is in node actually. However I would greatly appreciate some short wrap-up on the issue from someone who knows more what was going on.

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 15, 2016

Member

@quyse I believe this was the root cause: nodejs/node#5034

And yes, it looks like node fixed it! New versions of GHCJS will also work with versions of node that don't have this fix.

Member

3noch commented Mar 15, 2016

@quyse I believe this was the root cause: nodejs/node#5034

And yes, it looks like node fixed it! New versions of GHCJS will also work with versions of node that don't have this fix.

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 15, 2016

Member

@quyse Also, little known fact: you can get newer sdists of GHCJS here: http://ghcjs.luite.com/

I use them with stack regularly with great success.

Member

3noch commented Mar 15, 2016

@quyse Also, little known fact: you can get newer sdists of GHCJS here: http://ghcjs.luite.com/

I use them with stack regularly with great success.

@quyse

This comment has been minimized.

Show comment
Hide comment
@quyse

quyse Mar 15, 2016

Contributor

@3noch Yep, I think so too, but I don't see an easy way to understand what version of node.js contains the fix. And thanks for the link, I need to update then :)

Contributor

quyse commented Mar 15, 2016

@3noch Yep, I think so too, but I don't see an easy way to understand what version of node.js contains the fix. And thanks for the link, I need to update then :)

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Mar 15, 2016

Contributor

I was about to craft a new one based on that happy news.. but it's even better if it's already compiled !

@3noch we should probably update stack's ghcjs documentation no ? this looks like a more reliable source

Contributor

nrolland commented Mar 15, 2016

I was about to craft a new one based on that happy news.. but it's even better if it's already compiled !

@3noch we should probably update stack's ghcjs documentation no ? this looks like a more reliable source

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Mar 15, 2016

Contributor

unfortunately I can't boot with 20160315.. I get an error when booting on my mac and targeting http://ghcjs.luite.com/ (is it just me ?)

I am now building an sdist on my mac, to see if that makes a difference.. not sure why HsUnix.h causes problem.. is it an external dependency.. ?

cabal: Missing dependency on a foreign library:
* Missing (or bad) header file: HsUnix.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
Failed to install unix-2.7.1.0
Contributor

nrolland commented Mar 15, 2016

unfortunately I can't boot with 20160315.. I get an error when booting on my mac and targeting http://ghcjs.luite.com/ (is it just me ?)

I am now building an sdist on my mac, to see if that makes a difference.. not sure why HsUnix.h causes problem.. is it an external dependency.. ?

cabal: Missing dependency on a foreign library:
* Missing (or bad) header file: HsUnix.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
Failed to install unix-2.7.1.0
@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 15, 2016

Member

Could you post your stack.yaml?

Member

3noch commented Mar 15, 2016

Could you post your stack.yaml?

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Mar 15, 2016

Contributor

It goes : https://gist.github.com/nrolland/75535e7255c52da67a83

trying to pin down that node version too with nix. may be that's the culprit

Contributor

nrolland commented Mar 15, 2016

It goes : https://gist.github.com/nrolland/75535e7255c52da67a83

trying to pin down that node version too with nix. may be that's the culprit

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 15, 2016

Member

@nrolland That looks right. I've never used the nix feature, so that's the only thing I can think that would make it not work. I'm doing almost the exact same thing (minus nix) on my Mac. But I'm using a global installation of node.

Member

3noch commented Mar 15, 2016

@nrolland That looks right. I've never used the nix feature, so that's the only thing I can think that would make it not work. I'm doing almost the exact same thing (minus nix) on my Mac. But I'm using a global installation of node.

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Mar 16, 2016

Contributor

yes nix was the pb. (probably some dependency declaration missing somewhere..), I am all good as far as install is concerned after removing it


In summary, what I did to get rid of the pb was :

  • nvm install v5.8.0; nvm use v5.8.0; nvm alias default 5.8.0 then launch a new shell in case bad juju
  • modified my stack.yaml to point to a recent sdist ghcjs release "http://ghcjs.luite.com/master-20160315.tar.gz" (with no nix unfortunately cf above)
  • stack setup; stack build

ps : I would like to say a big Thank you to @awpr for finding and documenting the issue on node's end. I would certainly never have been able to pinpoint that down, and such is the case for many other users. so thank you..

Contributor

nrolland commented Mar 16, 2016

yes nix was the pb. (probably some dependency declaration missing somewhere..), I am all good as far as install is concerned after removing it


In summary, what I did to get rid of the pb was :

  • nvm install v5.8.0; nvm use v5.8.0; nvm alias default 5.8.0 then launch a new shell in case bad juju
  • modified my stack.yaml to point to a recent sdist ghcjs release "http://ghcjs.luite.com/master-20160315.tar.gz" (with no nix unfortunately cf above)
  • stack setup; stack build

ps : I would like to say a big Thank you to @awpr for finding and documenting the issue on node's end. I would certainly never have been able to pinpoint that down, and such is the case for many other users. so thank you..

@3noch

This comment has been minimized.

Show comment
Hide comment
@3noch

3noch Mar 16, 2016

Member

@nrolland Rock on!

Yes many thanks to those who solved it.

Member

3noch commented Mar 16, 2016

@nrolland Rock on!

Yes many thanks to those who solved it.

@tolysz

This comment has been minimized.

Show comment
Hide comment
@tolysz

tolysz Mar 16, 2016

Collaborator

Just a note:
I am using quite newer resolver lts-5.8; packages used to create this archive are aligned with the repo ghcjs.luite.com (using https://github.com/tolysz/ghcjs-stack ). It builds fine using node v5.8.0 and ghc-7.10.3

flags: {}

resolver: lts-5.8
compiler: ghcjs-0.2.0.9005008_ghc-7.10.3
compiler-check: match-exact

setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.9005008_ghc-7.10.3:
         url: "https://tolysz.org/ghcjs/lts-5.8-9005008.tar.gz"

Collaborator

tolysz commented Mar 16, 2016

Just a note:
I am using quite newer resolver lts-5.8; packages used to create this archive are aligned with the repo ghcjs.luite.com (using https://github.com/tolysz/ghcjs-stack ). It builds fine using node v5.8.0 and ghc-7.10.3

flags: {}

resolver: lts-5.8
compiler: ghcjs-0.2.0.9005008_ghc-7.10.3
compiler-check: match-exact

setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.9005008_ghc-7.10.3:
         url: "https://tolysz.org/ghcjs/lts-5.8-9005008.tar.gz"

@nomeata

This comment has been minimized.

Show comment
Hide comment
@nomeata

nomeata Sep 4, 2017

I am seeing this problem: Very recent ghcjs, based on GHC-8.0, and node version v6.11.2:

/tmp/gc-0.0.2 $ ghcjs --make Setup.lhs 
Linking Setup.jsexe (Main)
/tmp/gc-0.0.2 $ node Setup.jsexe/all.js configure --ghcjs
Configuring gc-0.0.2...
all.js: The program 'ghcjs' version >=0.1 is required but the version of
/home/jojo/.bin/ghcjs could not be determined.

Didn’t someone say the problem was fixed?

nomeata commented Sep 4, 2017

I am seeing this problem: Very recent ghcjs, based on GHC-8.0, and node version v6.11.2:

/tmp/gc-0.0.2 $ ghcjs --make Setup.lhs 
Linking Setup.jsexe (Main)
/tmp/gc-0.0.2 $ node Setup.jsexe/all.js configure --ghcjs
Configuring gc-0.0.2...
all.js: The program 'ghcjs' version >=0.1 is required but the version of
/home/jojo/.bin/ghcjs could not be determined.

Didn’t someone say the problem was fixed?

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Sep 17, 2017

Collaborator

@nomeata Unfortunately, many things could cause such a problem. What's the output of /home/jojo/.bin/ghcjs --numeric-version?

Collaborator

mgsloan commented Sep 17, 2017

@nomeata Unfortunately, many things could cause such a problem. What's the output of /home/jojo/.bin/ghcjs --numeric-version?

@nomeata

This comment has been minimized.

Show comment
Hide comment
@nomeata

nomeata Sep 18, 2017

The cause in my case was this bug, since then fixed in GHCJS: ghcjs/ghcjs#606

nomeata commented Sep 18, 2017

The cause in my case was this bug, since then fixed in GHCJS: ghcjs/ghcjs#606

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment