Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple versions of sharp in node_modules cause "Incompatible library version" error #1680

Closed
pieh opened this issue Apr 29, 2019 · 4 comments
Labels

Comments

@pieh
Copy link

pieh commented Apr 29, 2019

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 gatsbyjs/gatsby#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.

@lovell
Copy link
Owner

lovell commented Apr 29, 2019

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.

@pieh
Copy link
Author

pieh commented Apr 29, 2019

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.

@pieh pieh closed this as completed Apr 29, 2019
@supert56
Copy link

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? :)

@merijnponzo
Copy link

merijnponzo commented Jun 8, 2020

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

Repository owner locked and limited conversation to collaborators Jun 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants