Error when using on Fedora-based distro

[ninjadev64]

@brainiac744 was trying to use my project OpenDeck which uses this library on nobara 38, a Fedora-based distro.

This is the error:

(node:25895) UnhandledPromiseRejectionWarning: Error: Wrong JPEG library version: library is 62, caller expects 80

There are no issues with the library in OpenDeck (excluding #9) on Ubuntu-based distros other users are using. In the meantime, @brainiac744 is using node-elgato-stream-deck with jpeg-js. I'm sure they'd be happy to provide more details.

[Julusian]

My suspicion as to what is happening (based on a previous occurrence of this), is that electron is loading some version of libjpeg/libjpegturbo, which is then conflicting with the version provided by this library.

I can see that on ubuntu 22.04, electron is loading /lib/x86_64-linux-gnu/libjpeg.so.8, and nobara 38 is loading /lib64/libjpeg.so.62.
This library is being built using the 80 api, which matches the libjpeg version on ubuntu, but not nobara.

I am able to flip the versions around to force this issue on ubuntu, so I shall continue to look into this

---

I tried to reproduce this using opendeck, running nobara 38 livecd in a virtual machine. But did not have luck with using opendeck, I can install plugins, and I can see it is recognising a steamdeck, but I don't get any errors and no grid to configure anything for the streamdeck

Trying some of the examples from the streamdeck library directly on nobara and they work fine, pointing to it being because of being combined with electron.

[ninjadev64]

I think you might just need to resize the OpenDeck window to be larger so you can see the grid ;)

Thanks for looking into this, though!

[Julusian]

After a few hours of playing around with this, I am not sure how to resolve it. I have found a couple of ideas, none of them sound nice.

1. Use the libjpeg api instead of turbojpeg api, as doing that would allow for enabling symbol mangling which would avoid the collision. This api does look like a nightmare to use, so I will not be confident that the result of using it will work well or be at all stable.
2. Can we build libjpeg-turbo in a way that means its symbols will not collide with those loaded by electron? Yes, but this is a very fiddly process to perform during the build, we need to use a modified header file, and use objcopy to mangle the built static library. This is tedious and risks a symbol being missed which I wouldnt be surprised if it could cause weird seg faults or errors due to mixing memory spaces.
3. Perhaps this could detect that it is being used in electron on linux, figure out which version it has loaded and chose the correct build to load for that? It wouldnt be too hard to build against each possible version, I think there are only 3 likely versions. But does this also have a risk of something being mismatched and causing issues?
4. Build a wasm version, and load that when in electron on linux. This will have a possibly noticable performance penalty, but will be much better than jpeg-js.
5. It sounds like building libjpegturbo as a dynamic library and using dlopen to load it would also be a viable solution. https://stackoverflow.com/a/69863334 It does/might complicate deployment, but is much simpler than some other options

In fact, maybe I should do 4 anyway, to replace jpeg-js, then review the options once I have a better idea of how well it actually performs.

[Julusian]

oh right, 5 is even easier than I thought. Doesn't even need dlopen, as the symbol conflict is happening inside of the library not with its api, so doesnt even need any code changes.

[ninjadev64]

I've never used native bindings with Node so I don't have too much of a clue what you're talking about, but I hope you find a solution that works 👍

[Julusian]

I've never used native bindings with Node so I don't have too much of a clue what you're talking about, but I hope you find a solution that works 👍

That's fine, this is partly in case anyone has any suggestions and partly documenting my thoughts for future me when I question the decisions I made during this

[Julusian]

I have published a version v2.2.0-0 which I think will resolve this. But I suspect that it requires changes to electron config to make the library loadable.
I shall spend some more time looking into this before doing a final release.

This version includes the build config change for #9

[ninjadev64]

Awesome