How to resolve dependency Libffi.so.7()(64bit)?

English Install/Boot/Login
#1

Hello,

I am quite new to Linus, and I need your help to solve my « Problem: nothing provides libffi.so.7()(64bit) needed by openmp-extras-12.9-0.x86_64 ».

Some context: I am using a repurpose old AM4 x64 rig with Microos with a K3s Kubernetes to host my own services like Jellyfin. So far so good, system is working, transactionnal update are rolling, services are running. Though, I have a AMD radeon HD 5770 inside, and I would like to use it for Jellyfin hardware acceleration. After some digging, I need AMD GPU Kubernetes plugin and for that I need to install ROCm kernel (Installation guide) or latest AMD GPU Linux driver (Installation guide) (https://github.com/RadeonOpenCompute/k8s-device-plugin).

While following the ROCm install, I had 2 problems, first is I can’t had import the ROCm gpg key with the command :

sudo rpm --import https://repo.radeon.com/rocm/rocm.gpg.key System can’t create transaction lock because it’s read only system (In French: “erreur : Impossible de créer transaction verrou sur /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)”)

Then, while installing the rocm-dkms package, I have the dependency error :

« Problem: nothing provides libffi.so.7()(64bit) needed by openmp-extras-12.9-0.x86_64 ».

Can someone explain to me what is the problem ? For what I get, a dependency for the package is missing. When you create a package, shouldn’t all you dependencies by provided somewhere ?
How can I provide this library ? Should I build it myself ? Build a Kernel ?? How ???

#2

Tumbleweed uses already a newer version:

**erlangen:~ #** zypper se -is libffi        
Loading repository data... 
Reading installed packages... 

S  | Name          | Type    | Version        | Arch   | Repository 
---+---------------+---------+----------------+--------+------------------------ 
i+ | libffi-devel  | package | 3.3.git30-1.13 | x86_64 | openSUSE-Tumbleweed-Oss 
i  | libffi8       | package | 3.3.git30-1.13 | x86_64 | openSUSE-Tumbleweed-Oss 
i+ | libffi8-32bit | package | 3.3.git30-1.13 | x86_64 | openSUSE-Tumbleweed-Oss 
**erlangen:~ #**

Contents are:

[FONT=monospace]**erlangen:~ #** rpm -ql libffi8 
/usr/lib64/libffi.so.8 
/usr/lib64/libffi.so.8.1.0 
/usr/share/licenses/libffi8 
/usr/share/licenses/libffi8/LICENSE 
**erlangen:~ #**
[/FONT]

You may try cheating by creating the following links:

**erlangen:~ #** ln /usr/lib64/libffi.so.8 /usr/lib64/libffi.so.7 
**erlangen:~ #** ln /usr/lib64/libffi.so.8.1.0 /usr/lib64/libffi.so.7.1.0 
**erlangen:~ #** ll /usr/lib64/libffi* 
lrwxrwxrwx 1 root root    15 Aug 25 10:39 /usr/lib64/libffi.so -> libffi.so.8.1.0
lrwxrwxrwx 2 root root    15 Aug 25 10:39 /usr/lib64/libffi.so.7 -> libffi.so.8.1.0
-rwxr-xr-x 2 root root 43544 Aug 25 10:39 /usr/lib64/libffi.so.7.1.0
lrwxrwxrwx 2 root root    15 Aug 25 10:39 /usr/lib64/libffi.so.8 -> libffi.so.8.1.0
-rwxr-xr-x 2 root root 43544 Aug 25 10:39 /usr/lib64/libffi.so.8.1.0
**erlangen:~ #**
#3

This is the whole reason transactional server installation choice exists. In transactional server current root is read-only; all changes are applied to clone of current root which will become root after reboot.

You can simply ignore it; missing key will at most cause warnings.

In French:

When you post in English speaking forum always run programs in English locale and post exact output (copy-paste) in English, not your interpretation of it.

« Problem: nothing provides libffi.so.7()(64bit) needed by openmp-extras-12.9-0.x86_64 ».

Yes, current Tumbleweed is using newer libffi which bumped major version. Change in major version of shared library implies ABI change; which means it is not safe to fool system by linking newer version under older name. The best choice is to find package that you try to install that is built for Tumbleweed. Or build it yourself. Of course it will also need to be maintained as Tumbleweed is changing permanently.

It is theoretically possible to do one of

  1. Build (or find) libffi package with older library. Shared libraries with different major numbers can usually be installed in parallel. Of course, it may also cause conflicts inside application itself (if different parts are built against different libraries).
  2. Try to link libffi.so.8 as libffi.so.7, ignore dependency and hope it will work. This may completely fail if application depends on changed ABI, and it may fail in rather mysterious ways.

I would not recommend either of them unless you fully understand your application internals and are capable of debugging any resulting breakage.

Of course, the question is whether you really need Tumbleweed? Leap 15.2 includes older libffi which provides libffi.so.7.

When you create a package, shouldn’t all you dependencies by provided somewhere ?

This package is not built for Tumbleweed. So its dependencies were provided at the time it was built. It is just that system where you try to install it does not have these dependencies.

How can I provide this library ?

You got it backwards. The correct way is to build application against updated library. Anything else may or may not work and it may be extremely hard to debug if it does not work.

RPM dependencies have absolutely nothing to do with content of file system

**erlangen:~ #** ln /usr/lib64/libffi.so.8 /usr/lib64/libffi.so.7 
**erlangen:~ #** ln /usr/lib64/libffi.so.8.1.0 /usr/lib64/libffi.so.7.1.0

These links will be broken on next package update.

Graphics suddenly slow/non-existent after dist-upgrade. Tried troubleshooting without success
#4

According to ROCm release notes, it supports SLES 15 SP2 so there are fair chances it will also work on Leap 15.2. As release notes imply this software has kernel dependencies, are you sure it will work on TW with most recent kernel even if you solve pure installation issues?

#5

Why do make this statement?

These links will be broken on next package update
Nope. The hard links create additional names which do not belong to the package. Thus they will stay unaffected by updating the package.

#6

Because the question was about package dependency, not about missing file. File link won’t solve missing dependency in any way.

The hard links create additional names which do not belong to the package.

Thank you. I was not aware of this.

Thus they will stay unaffected by updating the package.

If you say so … who am I to argue.

After update one of your link will point to library from package before update and another link - to library from package after update.

#7

You ignore the missing dependency.

After update one of your link will point to library from package before update and another link - to library from package after update.
That’s intended behavior. If the cheat works for the current version it will work also when the package gets an update. There was a longstanding and annoying problem with some libcrypt and similar. Establishing the link stopped the issue, It never appeared again upon updating libcrypt.

Of course if the cheat doesn’t work don’t try to get it working, but solve the issue properly.