Gatsby: Mozjpeg bad dep

[Truemedia]

When creating a new gatsby instance I now get this error when installing node modules via yarn

ENONET: No such file lstat, mozjpeg (bunch of weird Unicode characters printed out).

[DanielRuf]

Hi, please provide the full terminal output (error & stacktrace) and the steps that you have done.

Also do node --version and yarn --version and provide their output too.

[Truemedia]

Sure here is the full error:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/pi/Code/bots/data-services/gatsby/node_modules/mozjpeg/\u0001�\u0017@@�\u000f\f@8\b@\u001eu0006\u0005@@@@@�\u0001�\u0001\b\u0003\u0004\u0002\u0002@\u0002@\u001c\u001c\u0001\u0001\u0005@@\u001c�'".
info If you think this is a bug, please open a bug report with the information provided in "/home/pi/Code/bots/data-services/gatsby/yarn-error.log".

Node v10.15.3
Yarn 1.15.2

[DanielRuf]

Sounds like a bug in Yarn. Please try to downgrade Yarn and try npm too.

[Truemedia]

So Iv'e tried npm before downgrading yarn and got this error (similar issue by look of it):

npm ERR! path /home/pi/Code/bots/data-services/gatsby/node_modules/mozjpeg
npm ERR! code ENOTEMPTY
npm ERR! errno -39
npm ERR! syscall rmdir
npm ERR! ENOTEMPTY: directory not empty, rmdir '/home/pi/Code/bots/data-services/gatsby/node_modules/mozjpeg'

Wiil try downgrading yarn now and post the results shortly.

[DanielRuf]

Can you remove node_modules before the next try?
This is another bug. Did you use another user or sudo to run the commands?

[Truemedia]

Same result with yarn 1.13 before and after removing node_modules

[Truemedia]

I use sudo as last resort but that didn't work either

[DanielRuf]

And previous Node.js versions have the same problem? Can this be reproduced with your lockfile?

In this case a small repo for reproducing and debugging this would be helpful.

[Truemedia]

Had one last attempt running yarn under sudo, no node_modules folder, no lock files (npm or yarn) and get same result.

This is only from running gatsby new with default starter, and then attempting to run yarn manually when it fails at that step being triggered automatically. The only other info I have is that I'm running this on raspian (32bit OS) Rasperry Pi 3B+ (ARM7)

[DanielRuf]

Can this be reproduced with your lockfile?

In this case a small repo for reproducing and debugging this would be helpful.

Please create a small repo with which we can reproduce this.

[Truemedia]

Sorry @DanielRuf I felt I was running in circle repeating myself with the simple command so I did some digging.

Found that the gatsby sharp plugin is where this issue stems from (only root package present that has imagemin as dep).

Imagemin includes mozjpeg which apparently has broken binaries/build at the moment:
https://github.com/mozilla/mozjpeg/issues/329

Because of this it fails at that step and messes up the whole install. I understand the image processing side is a big part of gatsby and this is most likely something mozjpeg need to fix on there size but for the time being I'm going to fork gatsby and put it a workaround since I only need gatsby for a light weight data sourcing solution at the moment.

[DanielRuf]

Can you lock it down using a lockfile?

[DanielRuf]

Not sure if this is really the cause as it does not mention your issue or did I oversee something?

What does the error log say?

[Truemedia]

Looks like a bad version getting caught with a ^version flag but outside the scope of node (mozjpeg is not node based). Not something than be reminded from the node side directly but will try my workaround after work tomorrow.

[polarathene]

@DanielRuf The gibberish in the mozjpeg package directory is likely binary. Problem might be hard for you to reproduce since the environment is 32-bit ARM v7 , not 64-bit x86 (what you're more than likely using).

@Truemedia Imagemin and sharp will attempt to use any pre-built binaries if they think they'll work. Sometimes though(such as with Alpine) they choose incompatible binaries, this is usually discovered during an install of packages as they run some tests to verify(but yarn by default is silent about them). Should those install tests fail, they then will attempt to build from source, that will work if the distro has the dependencies required to build from source. No idea if they all support 32-bit ARM v7, presumably they would.

For Imagemin, you can see if you have local packages from your distribution instead. WEBP is cwebp, PNG is pngquant, Mozjpeg should be mozjpeg, but you could use libturbo(usually default jpg package) in it's place perhaps. Sharp needs libvips iirc, it's docs list a bunch of conditions of where it's pre-built binaries are supported, one of those is the version of Node.

For Alpine, I would use local packages or build my own binaries of these, and copy them over to the node modules packages to replace the bad binaries and now they'd work.

[DanielRuf]

In this case we would probably see another error or he did not post the full error / stacktrace.

[polarathene]

@DanielRuf eh,

• 1st error says it couldn't find a file at the location(mainly because it was directory path + some binary as text presumably which obviously isn't valid),
• 2nd error states it's not happy because the directory isn't empty, which for whatever reason was a problem.

@Truemedia could first delete the node_modules directory(and perhaps clear the local package cache for npm/yarn), and try again. Most likely due to running on 32-bit and / or ARM v7 though?

Seems they support ARMv7

Install test and build from source if fail

OS detection, which you can see is rather generic, I know that it doesn't work on Alpine(it's detected as Linux but the binary isn't compatible). The internals for what that package does, lives in this other package..and then few others from that.

---

I think my assumptions are a safe bet :)

@Truemedia can go to that mozjpeg path location and in mozjpeg/vendor should be a binary file cjpeg, open up a terminal at that location and type ./cjpeg -v. If the binary is working alright, you'll get some lines printed out, otherwise an error.

[DanielRuf]

@DanielRuf eh,

• 1st error says it couldn't find a file at the location(mainly because it was directory path + some binary as text presumably which obviously isn't valid),
• 2nd error states it's not happy because the directory isn't empty, which for whatever reason was a problem.

Is this the full error / stacktrace and nothing before this?
Because node-gyp and Python and the rest of the native build stack would throw errors if they could not build the binaries or could not download them.

Looks like a bad version getting caught with a ^version flag but outside the scope of node (mozjpeg is not node based)

Sure, it is a normal Node.js package, see https://www.npmjs.com/package/mozjpeg

mozjpeg/vendor

Do you mean vendor/linux?
https://github.com/imagemin/mozjpeg-bin/tree/master/vendor/linux

Also see https://github.com/gatsbyjs/gatsby/issues/12633#issuecomment-473677642

[polarathene]

Is this the full error / stacktrace and nothing before this?
Because node-gyp and Python and the rest of the native build stack would throw errors if they could not build the binaries or could not download them.

@DanielRuf I'm not OP :) That would be @Truemedia

It doesn't seem like it's a build error from compiling or downloading. Does seem like it compiled successfully but with incompatible ABI to libjpeg-turbo.

Sure, it is a normal Node.js package, see https://www.npmjs.com/package/mozjpeg

The npm mozjpeg package is also maintained by Imagemin org on github, it hasn't been updated since Oct 2018 and fetches pre-builts from it's own releases page. I just saw the earlier linked comment mozilla/mozjpeg#329 , that isn't relevant to this issue for pre-built binaries.

When the pre-builts fail to work however, they then build from source using mozjpeg 3.2, this is relevant to the linked issue as it's not compatible with libjpeg-turbo 2.0 if that's the version on the system being used as a dependency.

So... that package is where the issue belongs. Anyone who is unable to use pre-builts and has the latest libjpeg-turbo is going to experience breakage with that package. They'll need to not only update to a newer version of mozjpeg, but mozjpeg itself has switched from autotools to CMake for building binaries.

I guess as it is currently, no error is thrown during the build, and there isn't a 2nd test to confirm the binary is working correctly if it compiled fine... thus as a user everything appears to have gone ok and during actual usage breakage occurs? (according to logs given though seems to be an issue during package installation).

Do you mean vendor/linux?

No, the OS isn't in the node_modules install location, it's just mozjpeg/vendor/cjpeg.

The npm package only uses the lib directory. Pre-built binary is downloaded to vendor, compiled from source places the binary in vendor

Also see #12633 (comment)

Yes... I did see that. If OP deleted their node_modules, why would an error about a directory not being empty occur?(or did OP mean same result as in the first log shared?) Perhaps run yarn --verbose which logs some errors that yarn can be silent about(but npm isn't).

EDIT: Above is still an assumption, I don't know for sure if I'm correct about the incompatibility issue, but seems it could be likely?

[DanielRuf]

Perhaps run yarn --verbose which logs some errors that yarn can be silent about(but npm isn't).

With the full error log we could say more ;-)

[Truemedia]

Sorry I ran out of time to test this during week, will take a look again this weekend

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[Truemedia]

@DanielRuf @polarathene Can confirm this works on Raspiberry Pi3+ now when I've updated to latest gatsby CLI version.

[ps-george]

I keep running into this problem on an ASUS chromebook, what was the accepted solution to this? To manually rebuild mozjpeg?

[j0hnm4r5]

I'm on a RPi 4, and I'm still getting this error.

[frederic-bonjour]

Hello guys,

I'm experiencing the same problem on a Raspberry Pi 4.
Any ideas to solve that?

Thanks!