Install /lib64/ld-lsb-x86-64.so.2 on Fedora Asahi Remix release 40?

How to install /lib64/ld-lsb-x86-64.so.2 on Fedora Asahi Remix release 40?

when I try run my app bellow message appear

$ /opt/licenses/lmgrd -c /opt/licenses/user.lic -l /home/Licenses/
qemu-x86_64-static: Could not open '/lib64/ld-lsb-x86-64.so.3': No such file or directory

what I did until now:

$ cat /etc/fedora-release
Fedora Asahi Remix release 40 (Forty)

$ find /usr/lib64 -name "ld-linux.so.*"

$ dnf provides */ld-lsb-x86-64.so.3
allow_vendor_change is disabled. This option is currently not supported for downgrade and distro-sync commands
Error: No matches found...

$ sudo dnf install redhat-lsb-core
Fedora 40 - aarch64 - Updates                                                                                                  
Package redhat-lsb-core-5.0-0.9.20231006git8d00acdc.fc40.aarch64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

$ rpm -qi glibc
Name        : glibc
Version     : 2.39
Release     : 22.fc40
Architecture: aarch64
Install Date: Mon 07 Oct 2024 04:08:10 PM UTC

$ lsb_release -a
LSB Version:	:core-5.0-aarch64:core-5.0-noarch
Distributor ID:	FedoraAsahiRemix
Description:	Fedora Asahi Remix release 40 (Forty)
Release:	40
Codename:	Forty
$ sudo find /lib /lib64 /usr/lib usr/lib64 -name "ld*.so*"
/usr/lib/ld-linux-aarch64.so.1

Is the ld-linux-aarch64.so.1 equivelant of ld-lsb-x86-64.so.2 form aarch64?

could you recommend any solution for that issue?

I extracted ld-lsb-x86-64.so.3 from redhat-lsb-core-5.0-0.9.20231006git8d00acdc.fc40.x86_64.rpm and moved it to the desired location, /lib64/ and made it executable by chmod +x. Unfortunately, this steps didn’t solve my problem.

qemu-x86_64-static: /lib64/ld-lsb-x86-64.so.3: Incomplete read of file header

The supported way to run x86_64 apps is muvm + FEX, which isn’t hooked up to binfmt yet. Install steam (this won’t actually install Steam, it’s just a launcher, but it’s the easiest way to get all the dependencies), then run muvm bash.

However, that probably won’t work anyway, because ld-lsb-x86-64.so.3 is a weirdo loader and not the standard x86-64 one. Apparently that’s in the redhat-lsb package. @ngompa @dcavalca should we be adding that to the FEX rootfs?

1 Like

No, the redhat-lsb package should basically never be installed. What needs this?

Rredhat-lsb is required by lmgrd, the License Manager Daemon used by FlexNet Publisher, which supports applications like AutoCAD, MATLAB etc. Unfortunately, this dependency ld-lsb-x86-64.so.3 isn’t limited to just the license manager; it also affects the graphical user interface :frowning:

https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Lmutil-error-lib64ld-lsb-x86-64-so-3-bad-ELF-interpreter.html

does this mean that, as of today, there is no alternative solution to work around this issue? :frowning:

It’s thankfully been ages since I had to use FlexLM, but there should be a way to deploy a standalone instance that advertises the license over the network, and have applications connect to it. I think they do have an aarch64 version as well, but no idea how easy it is to get or whether it’ll play well with the specific software you’re trying to use here.

Thank you for your interest in this issue. Unfortunately, Asahi Linux without lsb-x86-64.so.3 is unusable for me at the moment due to both the license server and the application that require it to operate.

@ngompa @dcavalca could you explain why the redhat-lsb package cannot be added to the FEX rootfs? Just to fill my uneducated curiosity.

Is it possible to deploy the entire application in a Docker container while enabling OpenGL 4.6 support that AsahiLInux offers?

I think the answer here is probably: This is an app that expects to run on RHEL and is not packaged to work across different distros. Since we are not RHEL, you will have to set up some form of container/rootfs yourself, it’s not something we can support out of the box.

In general, the muvm/FEX integration is intended to be able to support self-contained apps that are properly packaged to run across multiple distros. If you have an app that requires a specific distro and specific packages from that distro, that falls outside the scope of the default integration and you’re on your own. If we just add random packages to the RootFS it will eventually grow to be unmaintainably large, we have to limit things to core packages that are expected to be installed by largely portably-packaged software.

You could try building your own custom RHEL-compatible rootfs erofs image and pass it to muvm with the -f argument. You will also have to make sure it’s either compatible with our Mesa overlays and add them as -f arguments (the ones in /usr/share/fex-emu/overlays), or do your own packaging of the Asahi Mesa package as part of your rootfs.