fatal error: sass/context.h: No such file or directory on Linux/amd64

[brosenfi]

Hello - I am running into a problem installing in our build environment. I have much less control over that build environment than I would on my development machine - it is behind a firewall without access to github, and only accesses npm packages through an internal registry. Because of that, downloading the binaries fails as expected and the install falls back on a build - unfortunately the build is failing as well.

I have tried to conform to the guidelines for submitting this issue as best as possible - searched for existing issues and could not find any with solutions in this situation. Also, the node_modules/node-sass directory is not in the workspace after the installation fails (assuming it's cleaned up after the failure by npm) - and I have no way to upload the node-sass binary file either, so I am counting on the build working. Finally, the actual project directory has been replaced with <project_dir> here in the log.

npm -v
3.10.8
node -v
v6.8.0
npm -v process.versions
{ http_parser: '2.7.0',
node: '6.8.0',
v8: '5.1.281.84',
uv: '1.9.1',
zlib: '1.2.8',
ares: '1.10.1-DEV',
icu: '57.1',
modules: '48',
openssl: '1.0.2j' }
npm -p process.platform
linux
npm -p process.arch
x64

Output from the build process

node-sass@4.5.3 install <project_dir>/node_modules/node-sass
node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.5.3/linux-x64-48_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.5.3/linux-x64-48_binding.node":

connect EHOSTUNREACH 192.30.255.113:443

Hint: If github.com is not accessible in your location
try setting a proxy via HTTP_PROXY, e.g.

  export HTTP_PROXY=http://example.com:1234

or configure npm proxy via

  npm config set proxy http://example.com:8080

node-sass@4.5.3 postinstall <project_dir>/node_modules/node-sass
node scripts/build.js

Building: /usr/local/node-v6.8.0-linux-x64/bin/node <project_dir>/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
gyp info it worked if it ends with ok
gyp verb cli [ '/usr/local/node-v6.8.0-linux-x64/bin/node',
gyp verb cli '<project_dir>/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli 'rebuild',
gyp verb cli '--verbose',
gyp verb cli '--libsass_ext=',
gyp verb cli '--libsass_cflags=',
gyp verb cli '--libsass_ldflags=',
gyp verb cli '--libsass_library=' ]
gyp info using node-gyp@3.6.2
gyp info using node@6.8.0 | linux | x64
gyp verb command rebuild []
gyp verb command clean []
gyp verb clean removing "build" directory
gyp verb command configure []
gyp verb check python checking for Python executable "python2" in the PATH
gyp verb which succeeded python2 /usr/bin/python2
gyp verb check python version /usr/bin/python2 -c "import platform; print(platform.python_version());" returned: "2.6.6\n"
gyp verb get node dir compiling against specified --nodedir dev files: /usr/local/node-v6.8.0-linux-x64
gyp verb build dir attempting to create "build" dir: <project_dir>/node_modules/node-sass/build
gyp verb build dir "build" dir needed to be created? <project_dir>/node_modules/node-sass/build
gyp verb build/config.gypi creating config file
gyp verb build/config.gypi writing out config file: <project_dir>/node_modules/node-sass/build/config.gypi
gyp verb config.gypi checking for gypi file: <project_dir>/node_modules/node-sass/config.gypi
gyp verb common.gypi checking for gypi file: <project_dir>/node_modules/node-sass/common.gypi
gyp verb gyp gyp format was not specified; forcing "make"
gyp info spawn /usr/bin/python2
gyp info spawn args [ '<project_dir>/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args '<project_dir>/node_modules/node-sass/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '<project_dir>/node_modules/node-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/usr/local/node-v6.8.0-linux-x64/include/node/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/usr/local/node-v6.8.0-linux-x64',
gyp info spawn args '-Dnode_gyp_dir=<project_dir>/node_modules/node-gyp',
gyp info spawn args '-Dnode_lib_file=/usr/local/node-v6.8.0-linux-x64/$(Configuration)/node.lib',
gyp info spawn args '-Dmodule_root_dir=<project_dir>/node_modules/node-sass',
gyp info spawn args '-Dnode_engine=v8',
gyp info spawn args '--depth=.',
gyp info spawn args '--no-parallel',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.' ]
gyp verb command build []
gyp verb build type Release
gyp verb architecture x64
gyp verb node dev dir /usr/local/node-v6.8.0-linux-x64
gyp verb which succeeded for make /usr/bin/make
gyp info spawn make
gyp info spawn args [ 'V=1', 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory <project_dir>/node_modules/node-sass/build' g++ '-DNODE_GYP_MODULE_NAME=binding' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1' '-DV8_DEPRECATION_WARNINGS=1' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DBUILDING_NODE_EXTENSION' -I/usr/local/node-v6.8.0-linux-x64/include/node -I/usr/local/node-v6.8.0-linux-x64/src -I/usr/local/node-v6.8.0-linux-x64/deps/uv/include -I/usr/local/node-v6.8.0-linux-x64/deps/v8/include -I../../nan -fPIC -pthread -Wall -Wextra -Wno-unused-parameter -m64 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -std=c++0x -MMD -MF ./Release/.deps/Release/obj.target/binding/src/binding.o.d.raw -c -o Release/obj.target/binding/src/binding.o ../src/binding.cpp In file included from ../src/binding.cpp:3:0: ../src/sass_context_wrapper.h:8:26: fatal error: sass/context.h: No such file or directory compilation terminated. make: *** [Release/obj.target/binding/src/binding.o] Error 1 make: Leaving directory <project_dir>/node_modules/node-sass/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (<project_dir>/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack at emitTwo (events.js:106:13)
gyp ERR! stack at ChildProcess.emit (events.js:191:7)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 2.6.32-431.el6.x86_64
gyp ERR! command "/usr/local/node-v6.8.0-linux-x64/bin/node" "<project_dir>/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd <project_dir>/node_modules/node-sass
gyp ERR! node -v v6.8.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
Build failed with error code: 1

[saper]

It looks like libsass source code is not there during the build... can you check if it libsass is there under src?

[brosenfi]

Trying to figure a way to check that - I can't seem to find a way to get npm to not clean up the <project_dir>/node_modules/node-sass directory after the failed deployment.

[brosenfi]

I found a work-around for getting npm to keep the <project_dir>/node_modules/node-sass directory - using the --ignore-scripts install option . This isn't ideal though because the poistinstall script won't run, but at least I can see the package as it's downloaded. I can confirm from this that the src/libsass directory is there and appears to populated with the full libsass project / source.

[brosenfi]

Thanks to some help at npm I found the way to keep that failed install directory - set rollback=false ( https://docs.npmjs.com/misc/config#rollback ). I can confirm src/libsass is in the directory when the install fails with that postinstall script.

[brosenfi]

I believe I have identified the problem although my lack of control over the build environment means I need some help creating a solution. It appears that the condition 'libsass_ext == "" or libsass_ext == "no"' within /binding.gyp is not being matched when the default argument '--libsass_ext=' is provided to the node-gyp script by the postinstall script scripts/build.js. This of course results in not having libsass added as a dependency. I can test this in my build environment through what I have control over - which is running a preinstall script in my project - and from there I can execute node-gyp the exact same way it is executed via scripts/build.js. Here is the command that fails:

const path = require('path');
const spawnSync = require('child_process').spawnSync;
var nodeGypArgs = [require.resolve(path.join('node-gyp', 'bin', 'node-gyp.js')),
'rebuild', '--verbose', '--libsass_ext=', '--libsass_cflags=', '--libsass_ldflags=', '--libsass_library='];
console.log(process.execPath + ' ' + nodeGypArgs.join(' '));
spawnSync(process.execPath, nodeGypArgs, {cwd: path.join(<project_dir>, 'node_modules', 'node-sass'), stdio: 'inherit'});

If we simply change the libsass_ext argument to '--libsass_ext=no' then the build succeeds. The following builds successfully:

const path = require('path');
const spawnSync = require('child_process').spawnSync;
var nodeGypArgs = [require.resolve(path.join('node-gyp', 'bin', 'node-gyp.js')),
'rebuild', '--verbose', '--libsass_ext=no', '--libsass_cflags=', '--libsass_ldflags=', '--libsass_library='];
console.log(process.execPath + ' ' + nodeGypArgs.join(' '));
spawnSync(process.execPath, nodeGypArgs, {cwd: path.join(<project_dir>, 'node_modules', 'node-sass'), stdio: 'inherit'});

[saper]

I wonder what in your environment breaks this?

I just tried your non-working script and I got:

gyp info it worked if it ends with ok
gyp verb cli [ '/usr/local/bin/node',
gyp verb cli   '/home/saper/node_modules/node-sass/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild',
gyp verb cli   '--verbose',
gyp verb cli   '--libsass_ext=',
gyp verb cli   '--libsass_cflags=',
gyp verb cli   '--libsass_ldflags=',
gyp verb cli   '--libsass_library=' ]

• which is the same as you did - and the build proceeds happily.

What kind of shell are you using?

Hint: You can set LIBSASS_EXT environment variable to no when building - might be easier than hacking the files.

[brosenfi]

It's bash - the whole thing is being orchestrated by Jenkins by the way. I'm going to take a look at the node-gyp script and see how it's picking the arguments up.

[saper]

The next thing I noticed you are forced to use Python 2.6, but that should work as well.

[saper]

One more thing, how do variables in question look like in your node_modules/node-sass/build/config.gypi file?

[brosenfi]

Ah yes - thanks - the value in config.gypi looks like it confirms the problem:

"libsass_ext": 0,

It's being set to the default value for an integer variable.

[brosenfi]

Same thing for all the others set to an empty value by the way:

"libsass_ext": 0,
"libsass_cflags": 0,
"libsass_ldflags": 0,
"libsass_library": 0,

[saper]

I get:

    "libsass_ext": "",
    "libsass_cflags": "",
    "libsass_ldflags": "",
    "libsass_library": ""

[brosenfi]

Drilled down a bit further - which version of the nopt package do you have installed?

[nschonni]

Python 2.7 is reguired for node-gyp https://github.com/nodejs/node-gyp#installation

[brosenfi]

I've got a local test now that I can reproduce the issue in finally - it has Python 2.7 installed so I can confirm the slightly older version of Python installed in the build environment did not affect this issue. I think I can describe the whole situation at this point:

There is one specific change / fix in the nopt package npm/nopt@c3b8bf0 - versions prior to this change (2.*) will fail in the failure scenario I described above, but anything with that change / fix (>=3.0.0) will succeed. So the issue here is with the node-gyp dependency on nopt:

"dependencies": {
...
"nopt": "2 || 3",
...
},

This means anything in that range is valid - and we have a transient dependency in our project on nopt@2.1.1, so npm installs that and allows node-gyp to use it since it also satisfies the node-gyp dependency.

With that in mind, the test case can now be:

1. Create an empty directory with the following package.json:
   {
   "name": "test",
   "version": "1.0.0",
   "private": true,
   "description": "test",
   "scripts": {},
   "dependencies": {
   "nopt": "2.1.1",
   "node-sass": "4.5.3"
   },
   "devDependencies": {}
   }
2. npm install
3. cd node_modules/node-sass
4. The following will fail:
   node ../node-gyp/bin/node-gyp rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
5. The following will succeed:
   node ../node-gyp/bin/node-gyp rebuild --verbose --libsass_ext=no --libsass_cflags= --libsass_ldflags= --libsass_library=

[saper]

Thank you, this looks like it! npm/nopt#24 might be related. I only wonder what shall we do (except for bumping nlog dependency for us). Maybe make sure we don't pass those options if they are unset? They are rarely needed ( I think I am the only user of these :).

[brosenfi]

Yeah - I think not passing the options if they are unset then using node-gyp's support for setting default values on all of those variables should work well. So then binding.gyp would be updated to include:

'variables': {
'libsass_ext%': '',
'libsass_cflags%': '',
'libsass_ldflags%': '',
'libsass_library%': ''
},
...

And scripts/build.js would be updated to not pass the options that aren't set on the env like you said:

function build(options) {
var args = [require.resolve(path.join('node-gyp', 'bin', 'node-gyp.js')), 'rebuild', '--verbose'].concat(
['libsass_ext', 'libsass_cflags', 'libsass_ldflags', 'libsass_library'].filter(function(subject) {
return !!(process.env[subject.toUpperCase()]);
}).map(function(subject) {
return ['--', subject, '=', process.env[subject.toUpperCase()] || ''].join('');
})
).concat(options.args);
...

This all seemed to work properly in a simple test without any of those parameters set in the environment.

[stevenvergenz]

For posterity, I'd like to specifically mention the workaround: LIBSASS_EXT="no" npm install

[SkyzohKey]

I'd like to add that installing libsass via pacman solved the issue for me (Manjaro/Arch).

[robbie-cahill]

On mac with homebrew, "brew install libsass" fixed the issue. I think the problem was that libsass was not installed.

[SkyzohKey]

The issue is that while trying to compile node-sass, the headers for libsass are not found, because it is not installed on the computer. So any guy encountering that issue must install libsass in order to get the headers files properly installed, so that node-sass can get interfaces and stuff. 😋

[quant4s]

When I install node-sass on raspberry(raspbian stretch), I met the same mistake.
node version: 6.13
npm version: 3.10.10
node-sass verion: last version

[nick250386]

I also encountered a similar issue and any of the below approaches worked:

• LIBSASS_EXT="no" npm install (solution provided by @stevenvergenz above)

• Set the LIBSASS_EXT environment variable before running the 'npm install command'

• Install libsass before so that all the necessary library files are available for node-sass to install successfully.

NOTE: The libsass folder is not getting installed prior to 'node-sass' due to the value of the variable not being available.