Failed to install with node7: ZLIB_VERNUM != PNG_ZLIB_VERNUM

[dakk]

Today I tried to install lwip on ubuntu 16.04 and I get this error during the compilation phase:

   CC(target) Release/obj.target/lwip_decoder/src/lib/png/png.o
 In file included from ../src/lib/png/png.c:14:0:
 ../src/lib/png/pngpriv.h:805:4: error: error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the notes in pngpriv.h"
  #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
lwip_decoder.target.mk:165: recipe for target 'Release/obj.target/lwip_decoder/src/lib/png/png.o' failed

Am I missing something?

[rsoladan]

+1

[ajuste]

I believe I used to have this error with node 7.x. have you tried 6.x ? This Is just to narrow the cause; not a solution.

[danibram]

+1 in node 7, In node 6 works fine! Thanks @ajuste

[willbamford]

Looks like libpng and zlib require an update https://github.com/EyalAr/lwip/pull/258#issuecomment-281689203

[dakk]

Yep, with node6 it's working fine, thank you. I left the issue open for node7

[phw]

Node 7.4 and earlier is also working for me, 7.8 not. Haven't tried other versions in between, yet.

[gagge]

node 7.7.3 have the same issue it seems.

[mark-veenstra]

I have the exact same error using lwip v0.0.9 with Node v6.10.2 and npm version 4.4.4. I can't understand what is wrong.

[ragecryx]

I have this issue in node 6.10.2

[mark-veenstra]

Changing the lwip version in package.json to the development branch of this package solved the issue in Node v6.10.2:

Change the use of version 0.0.9 to https://github.com/Pajk/lwip#development

[dakk]

@mark-veenstra thanks; btw it's not a good idea using a development branch in production.

[mark-veenstra]

@dakk no it isn't but what to do if you have no other choice? Seems like Ubuntu is installing the latest Node 6.x version and I can't find a way to downgrade the NodeJS. Even if I could which versions should I use?

[dakk]

@mark-veenstra I'm doing the same (using it in production)

[edittler]

I have same error in macOS 10.12.4, using node v4.8.2 or v6.10.2.

[edittler]

Finally I solve my problem replacing lwip for pajk-lwip.

[ghost]

@edittler save my day. Have macOS 10.12.4 and I'm able to install it without error using node v6.0.0, but get the same error on node v6.10.2 and v.7.8.0.

[phoenix741]

Hi,

Waiting for a new version of this lib too. I have the same probleme with the last version of node 6

[picheli20]

@nahody same for me! Worked only with version 6.0.0.

Tip: if sameone needs to changes the node version quickly I recommend the nvm, it's a node version manager.

[spchuang]

+1

[edittler]

It works also in version 6.10.1 or less. The problem is in version 6.10.2.

[maxceem]

Same for me on macOS 10.12.3, failed on v7.9.0 and v6.10.2 but works on v6.10.1.

[slava-viktorov]

v7.9.0 ~/home/slava/.node-gyp/7.9.0/include/node/zlib.h #define ZLIB_VERSION "1.2.11" #define ZLIB_VERNUM 0x12b0 #define ZLIB_VER_REVISION 11 #define ZLIB_VERNUM 0x12b0 v6.9.1 #define ZLIB_VERSION "1.2.8" #define ZLIB_VERNUM 0x1280 #define ZLIB_VER_REVISION 8 #define ZLIB_VERNUM 0x1280

lwip/src/decoder/pnglibconf.h #define PNG_ZLIB_VERNUM 0x1280

lwip/src/lib/png/pngpriv.h if PNG_ZLIB_VERNUM != 0 && PNG_ZLIB_VERNUM != ZLIB_VERNUM error ZLIB_VERNUM != PNG_ZLIB_VERNUM \ "-I (include path) error: see the notes in pngpriv.h"

If you change the version of zlib to 0x12b0 in pnglibconf.h, then the project is compiled. And the tests are executed without errors.

It works, but it's not right ... Probably you need to connect the zlib directory from the project instead of the node directory.

[suits-at]

@slava-viktorov Changing the ZLIB_VERSION to 0x1280 (I am using Node: v6.10.3) worked for me, but this is still a very dirty fix...

[meszaros-lajos-gyorgy]

I've tried using the development version of pajk-lwip and it resolves the issues, but it introduces a new one:

png.obj : error LNK2001: unresolved external symbol png_save_uint_32 [...\node_modules\pajk-lwip\build\lwip_decoder.vcxproj]

I'm using node v.7.7.3 and node-gyp v3.6.1

Editing the ZLIB_VERNUM of node-gyp solves the issue, I can install lwip.

[fatso83]

I have manually tested a range of Node versions:

4.6.2 OK (used in Meteor 1.4)
4.8.4 NOT OK (used in Meteor 1.5.1)
6.10.0 OK
6.10.1 OK
6.10.2 NOT OK
7.3.0 OK
7.4.0 OK
7.5.0 OK
7.6.0 NOT OK
7.7.0 NOT OK
7.8.0 NOT OK
7.10.0 NOT OK

Hope this helps someone. Using a Node version manager you can install this using a working version on the same major version as you are currently using, and then after installing it, switch back to latest version of that major version.

P.S. An easier option might be to simply use a image manipulation library written solely in javascript. See below.

-- edit on July 19: added Node versions used in Meteor edit on Nov 3: added comment to a patch to replace with jimp

[arackaf]

For the benefit of anyone else in search of a solution, your best bet may be to give jimp a try. It has a similar (and sometimes simpler) API, with zero external dependencies, so no more struggling with node-gyp.

https://www.npmjs.com/package/jimp

[sp90]

Findings:

6.11.5 NOT OK
7.5.0 OK
8.5.0 NOT OK

[fatso83]

Just a follow up to my comment above: if all you care about is actually getting your image manipulation working in a short amount of time, you could just replace lwip with the pure-js jimp library. This will avoid all the noise from node-gyp forever. jimp has almost the same API, and my entire diff was like this:

Click to display diff

```diff commit 105c81da3230d2b985afdd087583ac0fc8303bce Author: Carl-Erik Kopseng Date: Fri Jul 21 01:55:18 2017 +0200 Use JIMP instead of LWIP for image resize closes #330 Rids us of at least one case of node-gyp. diff --git a/imports/startup/lib/methods/util/ImageUtil.js b/imports/startup/lib/methods/util/ImageUtil.js index 84bc13e..18e83a4 100644 --- a/imports/startup/lib/methods/util/ImageUtil.js +++ b/imports/startup/lib/methods/util/ImageUtil.js @@ -6,33 +6,27 @@ export default { throw new Meteor.Error('ImageUtils.resize() can only be called on the server!'); } + const Jimp = Npm.require('jimp'); const dataURIRegex = /^data:.+\/(.+);base64,(.*)$/; function resize(img) { - const width = img.width(); - const height = img.height(); + const width = img.bitmap.width; + const height = img.bitmap.height; const isLandscape = width > height; const newWidth = isLandscape ? maxDim : (maxDim / height) * width; const newHeight = isLandscape ? (maxDim / width) * height : maxDim; - img.resize(newWidth, newHeight, 'lanczos', (err, resizedImage) => { - if (err) { - Logger.error('Error resizing to thumbnail!', err); - } else { - encodeToBase64DataURI(resizedImage); - } - }); - } - function encodeToBase64DataURI(img) { - img.toBuffer('jpg', {quality: 80}, (err, resizedBuffer) => { - if (err) { - Logger.error('Error writing thumbnail to buffer!', err); - } else { - const base64Thumbnail = new Buffer(resizedBuffer, 'binary').toString('base64'); - onDone('data:image/jpeg;base64,' + base64Thumbnail); - } - }); + img.resize(newWidth, newHeight) + .quality(70) + .getBase64(Jimp.MIME_JPEG, (err, base64Thumbnail) => { + if(err) { + Logger.error('resize error', err); + throw err; + } + + onDone(base64Thumbnail); + }); } function getBase64ImageDataFromDataURI(dataURI) { @@ -43,8 +37,7 @@ export default { } if (dataURIRegex.test(dataURIImage)) { - const lwip = Npm.require('lwip'); - lwip.open(getBase64ImageDataFromDataURI(dataURIImage), 'jpg', (err, img) => { + Jimp.read(getBase64ImageDataFromDataURI(dataURIImage), (err, img) => { if (err) { Logger.error('Error opening image from buffer', err); } else { diff --git a/package.json b/package.json index 9d538c8..fd4de82 100644 --- a/package.json +++ b/package.json @@ -33,8 +33,8 @@ "deep-extend": "^0.4.1", "fibers": "^1.0.14", "iconv": "^2.2.1", + "jimp": "^0.2.28", "lodash": "^4.14.1", - "lwip": "^0.0.9", "material-ui": "^0.16.7", "message-box": "latest", "meteor-node-stubs": "^0.2.3", ```

[rochan]

This issue could be resolved by installing graphicsmagick locally. See graphicsmagick for more info

[miller45]

the matching zlib is included from my local node-gyp version (there are different node-gyp version in %USERPROFILE%/./node-gyp . The node-gyp version 4.4.2 has the right ZLIB_VERNUM=0x1280 in zlib.h. I could solve the problem by specficing a target version for node-gyp via commandline: SET NPM_CONFIG_TARGET=v4.4.2 npm config set target=v4.4.2 --global npm install --global sprity

[picheli20]

If you are using it on sprity-lwip extension I've done this extension https://github.com/xcaliber-tech/sprity-jimp using jimp instead

[jeaye]

@picheli20 Perfect. Thank you so much.

[epaminond]

@fatso83, thanks for posting results for different node-versions! This saved me lots of time!

[codan84]

Same issue on node 9.3.0

[michael-ts]

Ok, so I updated to node 8.11.1 on Windows so that I could get lwip to compile with Visual Studio 2017, only to find that now while the compiler gets invoked, there is this error...

[michael-ts]

pajk-lwip fails to build for me:

png.obj : error LNK2001: unresolved external symbol png_save_uint_32 [C:\Users\michael\git\node_modules\pajk-lwip\build\lwip_decoder.vcxproj]
C:\Users\michael\git\node_modules\pajk-lwip\build\Release\lwip_decoder.node : fatal error LNK1120: 1 unresoved externals [C:\Users\michael\git\node_modules\pajk-lwip\build\lwip_decoder.vcxproj]

One of the answers suggested editing a lwip header file, but how do you do this? The code isn't on my machine except after I install. If I edit it and re-built won't it just get overwritten? Temporarily changing node-gyp's zlib.h until after the install did work for me, though. Haven't tested yet.

[alexanderdejong]

Ok so for anyone having the same issues on Osx and having problems figuring this issue out with homebrew.

I'm on OSX and using brew to manage my packages but that didn't work, I switched to NVM. Here is what I did:

I uninstalled Node from Brew because it only allows you to install: node@4, node@6, node@8 and a few others.

Then I installed NPM (node package manager) and pulled in Node 7.5.0 as suggested by @fatso83 with: nvm install v7.5.0

[kolbma]

Can't you provide a version without this strict lib version dependency?

I mean this is all about the dynamic linking of libs. An application linked against version x.y.z should also run against a lib with version x.y.(z+n).

There are no breaking changes in those libs.

If node changes too often its provided zlib with breaking changes you should think about using your own zlib together with libpng and use static linking during build.

[GuyPaddock]

I was really hopeful with this solution:

The node-gyp version 4.4.2 has the right ZLIB_VERNUM=0x1280 in zlib.h. I could solve the problem by specficing a target version for node-gyp via commandline: SET NPM_CONFIG_TARGET=v4.4.2 npm config set target=v4.4.2 --global npm install --global sprity

But after this trick, I get this error when trying to run the application:

Error: The module '/theme/node_modules/node-sass/vendor/linux-x64-57/binding.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 51. This version of Node.js requires
NODE_MODULE_VERSION 57. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).

[hotrush]

Hello from 2020 where this issue is still actual

[xhyrom]

Hello from 2020 where this issue is still actual

Hello from 2023