This repository has been archived by the owner on Jul 24, 2024. It is now read-only.
Compilation fails in Node v5.0.0-rc.1 #1224
Comments
|
I'm suspecting something node-sass specific, I notice node-gyp is in the dependencies list, what's the reason for this? ideally now you should be relying on what ships with the latest npm (v2 and v3) because it has a version of node-gyp that should work properly. Mind you, it has note the correct url |
I suspect it's to work with |
9 tasks
|
What happens if you take nvm out of equation? |
|
@saper nvm doesn't officially support rcs yet (see nvm-sh/nvm#779), I just downloaded the tarball and put it in a correct place and it works. This should be equivalent to just unpacking the tarball and setting the PATH to point to the unpacked Node, that's effectively what nvm does after all. I'd be surprised if nvm was able to interfere here. That said, I've installed the 5.0.0-rc.1 via the official pkg installer file as well and used |
|
@rvagg what how does your node introduce itself? I have this now on a freshly compiled v5.0.0-rc.1:
@mgol I have reproduced this bug - but I think there is something with our node engines :) but your node reports v5.0.0-rc.1 correctly, I think! |
|
@saper Newer The |
|
@saper BTW, you seem to have an incorrect |
I realized it is incorrect - I wonder why (had to compile it myself)
look like GitHub gave me this: https://codeload.github.com/nodejs/node/tar.gz/v5.0.0-rc.1 which has length 36691549 and md5 of 977aaea4a16a808ee8f0c112e243470c https://github.com/nodejs/node/archive/v5.0.0-rc.1.tar.gz src/node_version.h looks like: #define NODE_MAJOR_VERSION 5 #define NODE_VERSION_IS_RELEASE 1 so it thinks it is "node v5.0.0", period. |
|
@saper That shouldn't matter too much to debug it here, though - your incorrect |
|
My "incorrect" node seems to look in the |
|
It seems that you are using npm@3, maybe that changes something... |
|
What happens if you try |
|
Node 5 will come with npm@3 included so I think you can't use it with npm@2. |
|
Node 5 will come with ***@***.*** included so I think you can't use it with ***@***.***
Why not? Seems to work here for now ...
|
|
@saper I'm not sure what's the official policy (I asked in npm/npm#9902 but with no response so far) but 90% of people will use the default (which will be npm@3) anyway. |
|
|
What is the version of |
|
BTW, if I run it from Node 4.2.1 (just remember to remove |
|
This is because you have node-gyp v3.0.1 and npm@3 makes you believe you have v3.0.3 :) |
|
Hah, you're right: So it seems npm@3 is still broken... |
|
Can you do the following: |
|
It is not npm@3's fault. You should have "migrated to npm@3 properly" and not have leftover packages hidden under the tree:) node's |
|
I've wiped I assume you didn't mean the duplicate |
|
And |
|
|
node-sass is not to blame after all, sorry for being mistaken. More: nodejs/node-gyp#787 (comment). |
|
node-sass is not to blame after all, sorry for being mistaken. More: nodejs/node-gyp#787 (comment).
I Told You So :)
|
|
on a serious note, given uptake of npm@3 I think we will need to print the |
I wasn't 100% wrong, though - nvm didn't break anything, I just didn't expect node-gyp to change its behavior depending on internal nvm variables... |
|
how did you fix this please ? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It might be a
node-gypissue, although the latest3.0.3release should be able to download headers for non-stable packages as long as they expose properprocess.releaseobject. But in Node v5.0.0-rc.1 I get the output at the bottom of this report. Note the incorrect https://nodejs.org/dist/v5.0.0-rc.1/node-v5.0.0-rc.1-headers.tar.gz URL instead of the one inprocess.release.headersUrl.I reported it upstream in nodejs/node-gyp#787 in case it's their issue.
The output:
The text was updated successfully, but these errors were encountered: