Skip to content
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
Closed

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

gromakovsky opened this issue Dec 11, 2015 · 67 comments

Comments

@gromakovsky
Copy link

@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
Copy link
Collaborator

@tolysz 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
Copy link
Contributor

@mgsloan 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
Copy link
Author

@gromakovsky 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
Copy link
Author

@gromakovsky 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
Copy link

@akegalj 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
Copy link
Author

@gromakovsky 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…

@erikkaplun
Copy link
Contributor

@erikkaplun erikkaplun 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.

@erikkaplun
Copy link
Contributor

@erikkaplun erikkaplun 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
Copy link

@akegalj 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.

@erikkaplun
Copy link
Contributor

@erikkaplun erikkaplun 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.

@erikkaplun
Copy link
Contributor

@erikkaplun erikkaplun 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
Copy link
Contributor

@mgsloan 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
Copy link
Contributor

@quyse 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
Copy link

@yamafaktory 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
Copy link
Contributor

@nrolland 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
Copy link
Member

@3noch 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
Copy link
Contributor

@nrolland 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
Copy link

@hanshoglund 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
Copy link
Collaborator

@tolysz tolysz commented Jan 9, 2016

Could anyone give a Docker example when it fails?

@quyse
Copy link
Contributor

@quyse 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
Copy link
Contributor

@mgsloan 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.

@drwebb
Copy link
Contributor

@drwebb 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
Copy link

@alios 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
Copy link
Contributor

@drwebb 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
Copy link

@dmjio dmjio commented Feb 7, 2016

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

@dmjio
Copy link

@dmjio 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
Copy link

@EugeneN 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
Copy link
Contributor

@nrolland 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
Copy link

@EugeneN 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
Copy link
Contributor

@quyse 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
Copy link

@EugeneN EugeneN commented Mar 15, 2016

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

@3noch
Copy link
Member

@3noch 3noch commented Mar 15, 2016

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

@quyse
Copy link
Contributor

@quyse 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
Copy link
Member

@3noch 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
Copy link
Member

@3noch 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
Copy link
Contributor

@quyse 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
Copy link
Contributor

@nrolland 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
Copy link
Contributor

@nrolland 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
Copy link
Member

@3noch 3noch commented Mar 15, 2016

Could you post your stack.yaml?

@nrolland
Copy link
Contributor

@nrolland 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
Copy link
Member

@3noch 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
Copy link
Contributor

@nrolland 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
Copy link
Member

@3noch 3noch commented Mar 16, 2016

@nrolland Rock on!

Yes many thanks to those who solved it.

@tolysz
Copy link
Collaborator

@tolysz 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
Copy link

@nomeata 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
Copy link
Contributor

@mgsloan 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
Copy link

@nomeata 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.