FS#80209 - [libimagequant] libimagequant.so.0 disappeared in 4.2.2-1

Attached to Project: Arch Linux
Opened by Julian Brost (julian) - Thursday, 09 November 2023, 20:51 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Friday, 10 November 2023, 11:07 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Massimiliano Torromeo (mtorromeo)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

The symlink libimagequant.so.0 disappeared with the update from libimagequant 4.2.1-1 to 4.2.2-1:

$ diff -us <(pacman -Qlp /var/cache/pacman/pkg/libimagequant-4.2.1-1-x86_64.pkg.tar.zst) <(pacman -Qlp /var/cache/pacman/pkg/libimagequant-4.2.2-1-x86_64.pkg.tar.zst)
--- /proc/self/fd/11 2023-11-09 21:46:25.332303720 +0100
+++ /proc/self/fd/12 2023-11-09 21:46:25.332303720 +0100
@@ -3,8 +3,7 @@
libimagequant /usr/include/libimagequant.h
libimagequant /usr/lib/
libimagequant /usr/lib/libimagequant.so
-libimagequant /usr/lib/libimagequant.so.0
-libimagequant /usr/lib/libimagequant.so.0.0.0
+libimagequant /usr/lib/libimagequant.so.0.0.4
libimagequant /usr/lib/pkgconfig/
libimagequant /usr/lib/pkgconfig/imagequant.pc
libimagequant /usr/share/


This results in the python-pillow package (10.1.0-1) no longer working properly:

$ python -c 'from PIL import Image'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.11/site-packages/PIL/Image.py", line 82, in <module>
from . import _imaging as core
ImportError: libimagequant.so.0: cannot open shared object file: No such file or directory


If the change in libimagequant was actually intentional, python-pillow probably needs a rebuild to link against libimagequant.so.0.0.4 instead.
This task depends upon

Closed by  Massimiliano Torromeo (mtorromeo)
Friday, 10 November 2023, 11:07 GMT
Reason for closing:  Fixed
Comment by Toolybird (Toolybird) - Thursday, 09 November 2023, 21:26 GMT
Arch is not doing anything special here. This looks like an upstream tooling issue related to rust and the C API. Have you reported upstream?
Comment by loqs (loqs) - Thursday, 09 November 2023, 21:55 GMT
https://github.com/ImageOptim/libimagequant/commit/e509cf6577b2d7149ae37a93959ddaaf119cf3fa
Comment by Toolybird (Toolybird) - Thursday, 09 November 2023, 22:17 GMT
Looks potentially related:

https://github.com/ImageOptim/libimagequant/issues/109
Comment by Toolybird (Toolybird) - Thursday, 09 November 2023, 22:51 GMT
Merging  FS#80210  here
Comment by Polarian (Polarian) - Friday, 10 November 2023, 00:35 GMT
The Github issue you have linked was closed as completed in July, the last (working) release `4.2.1` was released on 10th September (https://github.com/ImageOptim/libimagequant/releases/tag/4.2.1), which means any changes made should have been in that release.

Plus this issue is discussing cargo NOT building the shared object, not the soname change... so I doubt it is related, however the following might:

https://github.com/ImageOptim/libimagequant/commit/e509cf6577b2d7149ae37a93959ddaaf119cf3fa

Although it is difficult to figure out the offending commit(s) because of the poor commit naming. But within the `clippy` commits it appears there was some minor changes to the functions, which could cause ABI compatibility, so I assume that would explain the soname change... but yet why would you go from `0.0.0` to `0.0.4`?

It does seem like the commit above is the cause... but figuring out why this was changed is difficult.

Anyways I will leave it up to the package maintainers, just found this issue due to it breaking `gajim`.
Comment by Johannes Löthberg (demize) - Friday, 10 November 2023, 00:36 GMT
The issue is apparently that cargo-c decided to impose a notion of semver on how they do soname versioning which is rather nonsense and broke this. I've pushed a version of python-pillow rebuilt against the new version to testing now.

C.f. https://github.com/lu-zero/cargo-c/issues/345
Comment by loqs (loqs) - Friday, 10 November 2023, 00:47 GMT
I believe libvips also needs to be rebuilt.
Comment by Johannes Löthberg (demize) - Friday, 10 November 2023, 01:07 GMT
libvips rebuilt.
Comment by Toolybird (Toolybird) - Friday, 10 November 2023, 06:22 GMT
> cargo-c decided to impose a notion of semver on how they do soname versioning which is rather nonsense

Yes, hence my remark about the tooling. The change breaks the usual lib versioning convention. Recompiling solves the immediate problem...but the end result looks fragile and basically "not right"...especially in view of this comment [1]

$ find-libprovides libimagequant-4.2.2-1-x86_64.pkg.tar.zst
libimagequant.so=0.0.4-64

[1] https://github.com/ImageOptim/libimagequant/pull/112#issuecomment-1760092104
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 10 November 2023, 07:56 GMT
I should avoid packaging just before going to bed... Totally didn't see the missing symlinks, sorry.

I manually recreated the missing symlinks in libimagequant and tested PIL and libvips (pre-rebuild) and they work fine like that.

So for now I am releasing libimagequant-4.2.2-2 with this fix and hopefully cargo-c/libimagequant will fix themselves in the future.
Comment by Johannes Löthberg (demize) - Friday, 10 November 2023, 10:22 GMT
Everyone makes mistakes. I do think we need tooling to prevent this happening by accident. :)

I get the feeling that `cargo-c` will not be changed back to provide the behavior that's expected of C-ABI shared libraries. Unfortunately the extra symlinks also don't really help much here, other than for users who've performed a partial upgrade.

The depending packages have been rebuilt, and from now on any soname version change at all, even one that is _supposed_ to be ABI-compatible like `libimagequant.so.0.0.5`, will require rebuilding `python-pillow` and `libvips` because they now link directly against `libimagequant.so.0.0.4` rather than `libimagequant.so.0`.

(I can't wait for the new pacman release with the new automatic soname dependency support which would've at least lead to this not breaking anything, just people being unable to update.)
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 10 November 2023, 10:58 GMT
Right, didn't realize that.

A workaround would be a change such as this

```
--- a/imagequant-sys/Cargo.toml
+++ b/imagequant-sys/Cargo.toml
@@ -29,7 +29,7 @@ libc = "0.2.112"

[package.metadata.capi.library]
name = "imagequant"
-version = "0.0.4"
+version = "1.0.4"

[package.metadata.capi.pkg_config]
name = "imagequant"
```

The resulting package then correctly includes the symlinks

```
usr/lib/libimagequant.so
usr/lib/libimagequant.so.1
usr/lib/libimagequant.so.1.0.4
```

And rebuilt packages would link against `libimagequant.so.1` but I am not sure if it's something that we should do in this case.
Comment by Johannes Löthberg (demize) - Friday, 10 November 2023, 11:00 GMT
I don't think it's a good idea to make up our own soname versions. Thankfully I don't expect libimagequant to be planning on doing any soname version bumps anytime soon, based on the fact that they only set it to `0.0.4` in the hopes that it would work around the issue.

So I think the best course of action is to just leave it as-is for now and see how things develop.
Comment by Massimiliano Torromeo (mtorromeo) - Friday, 10 November 2023, 11:05 GMT
Makes sense.

I am going to close the issue then, thanks!

Loading...