image-webpack-loader
image-webpack-loader copied to clipboard
Mozjpeg test fails and then compilation fails
Just updated to v3 and during installation I got:
[email protected] postinstall /node_modules/mozjpeg
> node lib/install.js
⚠ The `/node_modules/mozjpeg/vendor/cjpeg` binary doesn't seem to work correctly
⚠ mozjpeg pre-build test failed
ℹ compiling from source
✖ Error: autoreconf -fiv && ./configure --disable-shared --prefix="/node_modules/mozjpeg/vendor" --bindir="/node_modules/mozjpeg/vendor" --libdir="/node_modules/mozjpeg/vendor" && make --jobs=8 && make install --jobs=8
Command failed: /bin/sh -c autoreconf -fiv
/bin/sh: autoreconf: command not found
at ChildProcess.exithandler (child_process.js:213:12)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (internal/child_process.js:827:16)
at Socket.<anonymous> (internal/child_process.js:319:11)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at Pipe._onclose (net.js:475:12)
Are you working with an older version of Ubuntu? Can you try sudo apt-get install autoconf autogen
I'm on OSX 10.10. It looks like it is a imagemin/mozjpeg issue.
Would you evaluate the possibility to stick with [email protected] until a new version of mozjpeg comes out? That is the latest version correctly installing on OS X as versions 5.1.0 onwards use an incompatible version on mozjpeg 😞
@pavelloz do you know what the impact is of this?
I tried to reproduce this problem and i failed on both OSX 10.11 and 10.12, dont have access to 10.10
@albertogasparin
Have you tried installing automake, autoconf, libtool?
From what I've read in here https://github.com/imagemin/mozjpeg-bin/issues/16 it might be the case of simply missing dependencies necessary to compile the sources.
Yes, by installing all of them I was able to compile mozjpeg on my machine. The point I was highlighting is that as those tools are not available by default (and the error message is not that helpful) this webpack plugin now looks broken on OS X. So, I was questioning if the benefits of mozjpeg v4 over v3 are worth the additional pain for your OS X users. For what I'm concerned, I can stick with image-webpack-loader v2 as it works fine across all our machines, but new users might go elsewhere because the installation fails or it has to be compiled on every npm install.
Running OSX 10.11 and I ran into same issue.
Not sure if updating to image-webpack-loader v3.x is a viable option for us right now since this can possibly lead to fairly cryptic build error.
@albertogasparin Did you eventually update?
No, I had to lock the version to v3, as it's to much of a hassle for all developers in my team. I hope that mozjpeg will eventually release a new version soon. Otherwise will need to fork/find a replacement whenever this v3 will stop working 😞
Is it enough for you if we put a warning in the readme that users of OSX 10.10 should install an older version?
On Fri, 2 Dec 2016, 17:55 Alberto Gasparin, [email protected] wrote:
No, I had to lock the version to v3, as it's to much of a hassle for all developers in my team. I hope that mozjpeg will eventually release a new version soon. Otherwise will need to fork/find a replacement whenever this v3 will stop working 😞
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/tcoopman/image-webpack-loader/issues/49#issuecomment-264503508, or mute the thread https://github.com/notifications/unsubscribe-auth/AACx6nq_qOIKYomoCCq1k4kFjud5yzvUks5rEE2TgaJpZM4KZ0zi .
I'm running into the same problem on mac 10.12.1. Not sure how to fix this.
I was able to get it working. This line will get it to build from source:
brew install libtool automake autoconf nasm (from Kevva)
... and then additionally installing libpng will fix some future headaches ...
brew install libpng (from AndyKenward)
I'm running MacOS Sierra 10.12.2 and was running into many of the same problems listed in similar threads. The mozjpeg pre-build test failed but I was able to build from source afterwards.
Hi there The solution you provided were not enough in my case, I first had to correct the brew installation itself. For posterity, and because this is one of the first issues that arises when googling, here are the steps that worked for me. I started from the brew FAQ "upgrading MacOS", http://docs.brew.sh/Common-Issues.html#upgrading-macos
- update XCode, run it, it will proceed to a few more installation
brew update(updates brew itself)brew upgrade(upgrades all the packages)npm uninstall image-webpack-loaderandnpm install image-webpack-loader
hope this helps :)
@albertogasparin Do you have a Package lock file that was generated from another OS? I faced this issue when a package-lock.json file was created in Windows system and then we tried to deploy the code in Jenkins(Linux) environment. Deleting the package-lock.json file solved the issue for me. Hope this helps
In Debian Buster, I had to install the package "dh-autoreconf", which provided the expected app autoreconf
I have the same problem on CentOS 7. Any solutions to this?
I have the same problem on Windows 11. Any solutions to this?