Sharp: Multiple versions of sharp in node_modules cause "Incompatible library version" error

Created on 29 Apr 2019  路  4Comments  路  Source: lovell/sharp

We are looking to bump sharp version from ^0.21 to ^0.22 in multiple packages we maintain at https://github.com/gatsbyjs/gatsby/, but we hit a problem when user would update just one of those packages - he would have some packages depending on sharp@^0.21 and some on sharp@^0.22, which seems to cause issues when loading bindings:

dlopen(/Users/misiek/dev/gatsby-starter-blog/node_modules/sharp/build/Release/sharp.node, 1): Library not loaded: @rpath/libglib-2.0.dylib
  Referenced from: /Users/misiek/dev/gatsby-starter-blog/node_modules/sharp/build/Release/sharp.node
  Reason: Incompatible library version: sharp.node requires version 6001.0.0 or later, but libglib-2.0.dylib provides version 5801.0.0

- Remove the "node_modules/sharp" directory, run "npm install" and look for errors
- Consult the installation documentation at https://sharp.pixelplumbing.com/en/stable/install/
- Search for this error at https://github.com/lovell/sharp/issues

My main question is - is this something that can be fixed? Or our best bet is to add extra checks to make sure user will use packages that depend on same sharp version (to workaround this issue)

For reference - here's PR in our repository bumping sharp version in all of our packages https://github.com/gatsbyjs/gatsby/pull/13646 (where I also noted this issue)

What is the output of running npx envinfo --binaries --languages --system --utilities?

System:
    OS: macOS 10.14
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 6.80 GB / 32.00 GB
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.9.0 - /usr/local/bin/node
    Yarn: 1.10.1 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 10.14. - /usr/bin/gcc
    Git: 2.19.1 - /usr/local/bin/git
  Languages:
    Bash: 3.2.57 - /bin/bash
    Perl: 5.18.2 - /usr/bin/perl
    PHP: 7.1.19 - /usr/bin/php
    Python: 2.7.10 - /usr/bin/python
    Ruby: 2.3.7 - /usr/bin/ruby
    Rust: 1.16.0 - /Users/misiek/.cargo/bin/rustup

What are the steps to reproduce?

(This is not minimal reproduction - just something I did to be able to quickly reproduce the issue)

What is the expected behaviour?

Multiple sharp versions nested in node_modules link to appropriate library versions.

Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?

Potentially, yes - depends on initial feedback (if this is something fixable).

Are you able to provide a sample image that helps explain the problem?

This issue doesn't relate to individual images.

question

Most helpful comment

Hi Michal, good to hear from you and hope all is well.

Two different versions of sharp using the same prebuilt version of libvips and its dependencies, e.g. v0.22.x and v0.22.y, should co-exist peacefully.

Two different versions of sharp using different prebuilt versions of libvips and its dependencies, e.g. v0.21.x and v0.22.x, will not be able to co-exist in the same Node process (although they could live alongside each other in node_modules filesystem).

As you've discovered, this is due to conflicting shared library versions; whichever is required first "wins".

The safest way to have different versions co-existing is to rely on a globally-installed libvips, but this means compiling from source at npm install time, which is probably not the experience you want to offer.

Perhaps you could move the sharp dependency to its own minimal common/core/parent package that other packages within the Gatsby monorepo could then depend upon? That might reduce the support burden a little.

All 4 comments

Hi Michal, good to hear from you and hope all is well.

Two different versions of sharp using the same prebuilt version of libvips and its dependencies, e.g. v0.22.x and v0.22.y, should co-exist peacefully.

Two different versions of sharp using different prebuilt versions of libvips and its dependencies, e.g. v0.21.x and v0.22.x, will not be able to co-exist in the same Node process (although they could live alongside each other in node_modules filesystem).

As you've discovered, this is due to conflicting shared library versions; whichever is required first "wins".

The safest way to have different versions co-existing is to rely on a globally-installed libvips, but this means compiling from source at npm install time, which is probably not the experience you want to offer.

Perhaps you could move the sharp dependency to its own minimal common/core/parent package that other packages within the Gatsby monorepo could then depend upon? That might reduce the support burden a little.

I'm good! Thanks!

Also thanks for very quick answer! This is pretty much what I thought (after doing some .dylib version checks manually in my node_modules - they were reporting "correct" version, so it seemed to be runtime issue and not install-time issue.

We might investigate spawning extra processes in the future (so each runtime would be safe to use whatever version), but for now we will go with adding warning/error message instructing how to fix Incompatible library version when using Gatsby packages.

Sorry I see this is closed but have just hit this problem with Gatsby running v2.13.73 and am getting the message sharp.node requires version 6001.0.0 or later, but libglib-2.0.dylib provides version 5801.0.0.

@pieh Is there a quick solution to this at all that could be shared as it seems to make it impossible/tricky to upgrade versions? :)

I am having this issue with versions:

 Reason: Incompatible library version: sharp.node requires version 6401.0.0 or later, but libglib-2.0.0.dylib provides version 6201.0.0

package.json

 "engines": {
    "node": ">= 10.0.0",
    "npm": ">= 6.0.0"
  },
  "dependencies": {
    "aws-sdk": "^2.686.0",
    "sharp": "0.25.1"
  },

when i run npm run install
i got

info sharp Using existing vendored libvips v8.9.1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jaydenseric picture jaydenseric  路  3Comments

natural-law picture natural-law  路  3Comments

emmtte picture emmtte  路  3Comments

jaekunchoi picture jaekunchoi  路  3Comments

sansroman picture sansroman  路  3Comments