imhex: update to 1.38.1.

[Rutpiv]

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture (x86_64)
• I built this PR locally for these architectures using specific masterdirs:
  • x86_64-musl
• I built this PR locally for these architectures (crossbuilds):
  • aarch64
  • aarch64-musl

[Rutpiv]

During testing, the build and install process appears to require the patterns directory to be named exactly ImHex-Patterns in order to complete correctly.

For this reason, the extracted ImHex-Patterns-ImHex-v${version} directory is renamed to ImHex-Patterns in post_extract, matching what upstream expects during installation.

This update also installs a few additional resources from ImHex-Patterns that are not installed by default upstream, but are present in the patterns repository and can be used by the application at runtime:

• disassemblers
• plugins
• scripts
• themes
• tips

The SDK directory (/usr/share/imhex/sdk) is no longer installed.
It significantly increases the package size and appears to be primarily intended for external plugin development rather than regular application usage. Other distributions also seem not to ship the SDK as part of the default installation.

The SDK could be split into a dedicated package, for example imhex-plugin-sdk, keeping the main package lean while still providing support for plugin developers. I can add this to the template if it makes sense. Alternatively, we can revert to the previous state and keep the SDK bundled together if that is preferred.

[classabbyamp]

split the sdk, it's useful

[Rutpiv]

Thanks. I’ve split the plugin SDK into a separate subpackage, imhex-plugin-sdk.

[JkktBkkt]

This fails to build if llvm18 has been built with -o lto, solution is simple — rebuild llvm18 with -o ~lto

[Rutpiv]

@JkktBkkt confirmed. I reproduced the issue locally by rebuilding llvm18 with LTO enabled. The failure is an unresolved llvm::demangle symbol at link time.

I made the changes in this PR based on the default configuration users get from the repositories. By default, llvm18 is built without LTO, but I also looked into the LTO case you described to see if it could be handled cleanly.

I’ve opened a separate PR that attempts to address this by adding the missing demangle linkage when building against the system LLVM with LTO enabled. I tested this by rebuilding and compiling imhex with that change applied, and everything appears to work correctly on my side.

#58322