search

WerWolv / ImHex

🔍 A Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM.
https://imhex.werwolv.net
GNU General Public License v2.0
44.77k stars 1.95k forks source link

ArchLinux package launch failure because of .so file missing #1532

Open iTrooz opened 9 months ago

iTrooz commented 9 months ago

This issue tracks the recurring problem with the ArchLinux artifact failing to launch with the error imhex: error while loading shared libraries: libmbedtls.so.<version>: cannot open shared object file: No such file or directory (or any other library, but here we are going to focus on mbedtls)

This is caused by an upgrade of the mbedtls library by ArchLinux. When this happen, AUR packages have the responsibility to update their packages.

A potential solution considered for the long term future is to embed mbedtls statically for the ArchLinux package (but at this point why not just use the AppImage ?)

In case some people are wondering, here is the reason we don't link against openssl instead: https://github.com/WerWolv/ImHex/issues/173

Please do not spam on every breakage, one message per breakage will be enough for me to update the package

Conversation on discord: https://discord.com/channels/789833418631675954/789838296376803358/1203672392577056828

RocketMaDev commented 8 months ago

I may suffer from this problem. When installed imhex-bin and run imhex, apparently the lib to be linked is a bit old. I have libmbedtls.so.20 but it requires libmbedtls.so.19.

xangelix commented 4 months ago

@iTrooz Arch just bumped everything to mbedtls 3.6.0 in the testing repo. Unfortunately, this will become an issue again for those on arch stable shortly, (for those using imhex-bin)

iTrooz commented 4 months ago

This issue is now the official one for reporting these breakages

iTrooz commented 4 months ago

Notice for maintainer (me): how to update ArchLinux imhex-bin package in case of breakage

iTrooz commented 4 months ago

Package should be working now :)

WerWolv commented 4 months ago

What's the reason exactly they're doing it like that? Versioned libraries make sense if you have constant ABI breaks but then the old versions need to be kept around. Like this it just guarantees to break every single application that depends on the library for absolutely no reason...

iTrooz commented 4 months ago

ArchLinux already works around these ABI breaks by updating all packages depending on the library at once. The real issue is for binary AUR packages, which aren't updated in this atomic manner.

And ArchLinux maintainers doesn't support fully AUR (it's more of a bonus list of build scripts maintained by the community), much less binary AUR packages (in case of an open source software, AUR packages are supposed to build from source, not merely install a binary built by Github Actions)

Moreover, if they had to maintain every major version of every package, this would create more work for little use (just some binary AUR packages)

More info: https://www.reddit.com/r/archlinux/comments/15lfklk/why_doesnt_archlinux_keep_old_major_versions_of/

WerWolv commented 4 months ago

Wouldn't this all be a non-issue though if they just shipped a libmbedtls.so.whatever and symlinked it to libmbedtls.so? That way we could simply link against the unversioned one and have it automatically use the latest one. That's how many other distros handle it too

iTrooz commented 4 months ago

This wouldn't work because we would then be linking against another ABI than the one we linked against e.g. We build against libmbedtls.so.19, then distribute the binary, then ArchLinux replaces it with libmbedtls.so.20. Now our application would try to use the libmbedtls.so.19 ABI against the libmbedtls.so.20 binary. The right thing to do in that case is for us to rebuild against libmbedtls.so.20

I don't think any distribution would do this, since it would be dangerous (and very probably UB) to interact with a different ABI than the one provided at compile-time

WerWolv commented 4 months ago

In most cases the ABI should not change though, especially not in-between minor versions unless they keep changing function signatures and structs.

A break like that makes sense between e.g mbedtls 2 and mbedtls 3 but not from 3.1 to 3.2.

It's easy to test though. Simply symlink libmbedtls.so.20 to libmbestls.so.19. If it works, there was no point in upping the so version

iTrooz commented 4 months ago

True, but maybe this is what happens (frequent ABI changes). I haven't looked into why the soname changes so often

It's easy to test though. Simply symlink libmbedtls.so.20 to libmbestls.so.19. If it works, there was no point in upping the so version

Or we don't use such a symbol that was changed

RocketMaDev commented 4 months ago

In most cases the ABI should not change though, especially not in-between minor versions unless they keep changing function signatures and structs.

A break like that makes sense between e.g mbedtls 2 and mbedtls 3 but not from 3.1 to 3.2.

It's easy to test though. Simply symlink libmbedtls.so.20 to libmbestls.so.19. If it works, there was no point in upping the so version

Yes, I do like this. As an Arch Linux user, when this case happens, I symlink, for instance, .20 version to .19 version, and everything works. A good library should have good backward compatibility.

iTrooz commented 4 months ago

https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.0

Sounds like the API changes mentioned would be enough to mandate a new soname (renamed a public function)