Sharp: GLib-GObject:ERROR with Linux and Electron

[ion-dev]

Sharp: v0.26.0
Electron: v7.1.7

We have an Electron app that runs on Linux x64. Installing sharp works fine using 'npm i sharp'.

However, when we require sharp in Electron it throws an error on launch.

For example, as soon as we add this line to main.js:

const sharp = require('sharp');

it throws this error:

GLib-GObject:ERROR:../gobject/gvaluetypes.c:454:_g_value_types_init: assertion failed: (type == G_TYPE_CHAR)

Tested on macOS and Windows and everything works perfectly. Only Linux is the issue. Tested on 5 different developer Linux machines and all throw the same error.

We also tested on a really basic app with little more than sharp installed and we got the same error.

We've also tested Electron versions 8, 9 and 10 - same error!

We've followed the install guide on sharp.pixelplumbing.com/install.

Any ideas?

System:
OS: Linux 4.15 Ubuntu 18.04.5 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
Shell: 4.4.20
Binaries:
Node: 12.15.0
npm: 6.13.4

[lovell]

a really basic app with little more than sharp installed

Is canvas also a dependency? If so, please see #612 and the issues it links to.

[ion-dev]

a really basic app with little more than sharp installed

Is canvas also a dependency? If so, please see #612 and the issues it links to.

No, we don't have canvas and it's not installed by any other dependencies.

[ion-dev]

@lovell here's a demo app you can you to test on Linux:
https://github.com/dev-manager-uk/image-resize-test

npm i
npm start

You should get the error!

[lovell]

Thanks, I think this is caused by the prebuilt libvips binary provided by sharp switching from shared to static libraries as part of v0.26.0.

The Linux binary provided by electron depends on the global glib shared library, which is causing a conflict.

$ ldd node_modules/electron/dist/electron | grep glib
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f9733040000)

Hopefully https://github.com/lovell/sharp-libvips/issues/60 will help with this.

[kleisauke]

I can confirm that https://github.com/lovell/sharp-libvips/issues/60 fixes this issue.

(tested by swapping the libvips binaries within the node_modules/sharp/vendor/8.10.0/lib directory with the binaries built from PR https://github.com/lovell/sharp-libvips/pull/62)

[ion-dev]

@lovell @kleisauke I can confirm it works by copying the correct contents into node_modules/sharp/vendor/8.10.0/

Do you have any idea when this fix will be released?

[dev-manager-uk]

Is there are way we can build this for linux possibly? Thanks :-)

[catdad]

I am having the same issue. Interestingly, I should note that my app already has sharp as optional, and it wraps the require in a try/catch to handle any errors with importing sharp. This error, however, directly crashes the process (it exists with SIGABRT) and does not seem to be able to be handled. I understand that it might be a significant amount of work to fix the error, but would it be possible to make this error handlable so that we can include sharp as optional?

[lovell]

@catdad The prebuilt binaries provided from forthcoming v0.27.0+ will address this for sharp, so you'll have to wait. It is equally incumbent upon Electron to solve this on a more long term basis for other native modules by switching to static linking.

[inukshuk]

Has anyone had success with Electron and the statically linked libvips? Compiling sharp for Electron 11 linked to a libvips build with the latest version of lovell/sharp-libvips solves the crash mentioned in the OP. However, when I try to load an image (same result for all supported formats) I always get this error:

[basic_string::_S_construct null not valid]

Has anyone else run into this? It's hard for me to tell where this is coming from. Initially, I thought I could use backtrace in gdb to get closer, but this is not a segfault but an error that is handled and returned by sharp.

It's worth noting that Electron 11 and sharp 0.26 work fine when linked against the my system libvips 8.10.2 (linked against more libs than the vendored variant even). I also tried building libvips 8.10.2 with the sharp-libvips script and adjusting the version in sharp's package.json to get it to accept a vendored 8.10.2 but this results in the same error.

[lovell]

sharp v0.27.0 now available with a prebuilt libvips v8.10.5 - thanks for reporting this.