Sharp: Error: /srv/api/node_modules/sharp/build/Release/../../vendor/lib/libvips-cpp.so.42: file too short

Created on 9 Feb 2018  路  4Comments  路  Source: lovell/sharp

I am getting the following error when starting my nodejs application on the AWS server:
Error: /srv/api/node_modules/sharp/build/Release/../../vendor/lib/libvips-cpp.so.42: file too short

The npm install is working fine and it is also working on my local environment: macOS High Sierra.

On the server side, I am using a docker image based on ubuntu.

question

Most helpful comment

So many threads about all sorts of related problems. I discovered what is causing all of them potentially.
I use a VirtualBox VM of Ubuntu but I've mounted the VM Host's FileSystem a Windows 8.1 box via the mount command from a NetworkShare folder.
It does not allow symbolic links.
Only when I copied the npm project folder to the root (Not mounted FS) did npm rebuild solve the endless problems with the sharp dependency not building.
When I tried to copy the working one back to the mount point it reports that symbolic links can't be created. All the help I've found says you can override with a flag in Windows but this is a Share internal to the VM not via the NFS 'mount'. I'm still looking for a solution other then leaving real code buried in a VM's VDI (not cool).
Normally I found ways around via npm flags like --unsafe-perm --no-bin-links but for this sharp building .o for numjs over an NFS mount it seems impossible.
I've initially tried to unpack a tar.gz on the Windows side and then I get this file too short error. I'll keep searching for a way but maybe there's some insight. We should link to this explanation on the dozens of threads I waded through for hours that all seem to be potentially related. @lovell

All 4 comments

Hello, it sounds like that file has become truncated or otherwise corrupt. Has a large enough filesystem been allocated? What does running ls -al /srv/api/node_modules/sharp/vendor/lib display?

So I managed to get it working by entering on the container after I deployed it to my amazon server and deleting the node_modules folder and running npm install again. For some reason it worked but I still have to figure it out how to make it work with my current build/deploy process.

Issue 637 gave me a way to go. btw, I am using v0.19.0. Maybe #861 didn't solved it?

If I try to run npm rebuild instead of deleting the folder and installing it all over, I get the following error:

```> [email protected] install /pipeline/source/node_modules/sharp

node-gyp rebuild

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info spawn /usr/bin/python2.7
gyp info spawn args [ '/usr/local/lib/node_modules/npm/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 '/pipeline/source/node_modules/sharp/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '/usr/local/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/root/.node-gyp/7.0.0/include/node/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/root/.node-gyp/7.0.0',
gyp info spawn args '-Dnode_gyp_dir=/usr/local/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args '-Dnode_lib_file=node.lib',
gyp info spawn args '-Dmodule_root_dir=/pipeline/source/node_modules/sharp',
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=.' ]
/bin/sh: 1: brew: not found
gyp: Call to 'which brew >/dev/null 2>&1 && eval $(brew --env) && echo $PKG_CONFIG_LIBDIR || true' returned exit status 0 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: gyp failed with exit code: 1
gyp ERR! stack at ChildProcess.onCpExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:305:16)
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 4.8.11-coreos-r2
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /pipeline/source/node_modules/sharp
gyp ERR! node -v v7.0.0
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok

npm info lifecycle [email protected]~install: Failed to exec install script
npm ERR! Linux 4.8.11-coreos-r2
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "rebuild"
npm ERR! node v7.0.0
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE
npm ERR! [email protected] install: node-gyp rebuild
npm ERR! Exit status 1```

Thanks for the update. npm install / npm rebuild has to occur on the runtime platform when there are native modules within node_modules. Good luck!

So many threads about all sorts of related problems. I discovered what is causing all of them potentially.
I use a VirtualBox VM of Ubuntu but I've mounted the VM Host's FileSystem a Windows 8.1 box via the mount command from a NetworkShare folder.
It does not allow symbolic links.
Only when I copied the npm project folder to the root (Not mounted FS) did npm rebuild solve the endless problems with the sharp dependency not building.
When I tried to copy the working one back to the mount point it reports that symbolic links can't be created. All the help I've found says you can override with a flag in Windows but this is a Share internal to the VM not via the NFS 'mount'. I'm still looking for a solution other then leaving real code buried in a VM's VDI (not cool).
Normally I found ways around via npm flags like --unsafe-perm --no-bin-links but for this sharp building .o for numjs over an NFS mount it seems impossible.
I've initially tried to unpack a tar.gz on the Windows side and then I get this file too short error. I'll keep searching for a way but maybe there's some insight. We should link to this explanation on the dozens of threads I waded through for hours that all seem to be potentially related. @lovell

Was this page helpful?
0 / 5 - 0 ratings