LoongArch Linux distros currently do not supply libutil.so, against LSB 5.0

[Icenowy]

As the LoongArch support of glibc is merged after glibc cancels libutil.so, this shared object just does not exist on LoongArch systems utilizing glibc.

However, in LSB 5.0 Generic Core part (adapted as an ISO standard, ISO/IEC 23360-1-2:2021), it requires a libutil library with soname of "libutil.so.1" as defined in [1].

As LSB does not have a architecture-specific variant for LoongArch, should its Generic part be complied on LoongArch?

[1] https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libutil.html

[Icenowy]

Reported to glibc upstream as https://sourceware.org/bugzilla/show_bug.cgi?id=31136 .

[xry111]

Since Glibc 2.34 libutil has been merged into libc, and an empty libutil.a is provided for backward compatibility. On LoongArch the first supported Glibc version is 2.36, so there should be nothing depending on libutil.so.1.

LSB only exists for ABI compatibility with pre-compiled binaries but on LoongArch no such a pre-compiled binary depending on libutil.so.1 should ever exist: even if a package specifies -lutil at linking, it should just link to the empty libutil.a w/o creating a DT_NEEDED for libutil.so.1.

[jiegec]

The problem is, some applications dlopen() libutil.so.1 instead of linking.

[xry111]

The problem is, some applications dlopen() libutil.so.1 instead of linking.

Then isn't the entire point of dlopen'ing a shared object is to support both the conditions it exists and not? What's the point to dlopen a shared object and assume it always exists instead of linking to it?

[xen0n]

The problematic package is a Java one dlopen-ing libutil.so, for manipulating PTYs it seems. (It's part of the JetBrains packages.)

My opinion is that this package should get adapted, propagating its new version through deps to finally get a fixed JetBrains distribution, but I think OP is in support of having a compatibility file in place so the users could get a working JetBrains soon without having to wait for the version bump (that could take ages).

[xen0n]

The problem is, some applications dlopen() libutil.so.1 instead of linking.

Then isn't the entire point of dlopen'ing a shared object is to support both the conditions it exists and not? What's the point to dlopen a shared object and assume it always exists instead of linking to it?

Existing versions of low-level bindings of those libraries for high-level languages often don't get updated, and on the older arches it's not a problem because those .so's are already part of the ABI and can't be removed. It's just LoongArch that happened to be a very recent invention, after most of the community's collective innovations have taken place, that some older ways of doing things do not exist. You can say the same to the fstat -> statx headache and possibly much more.

[xry111]

There's no way to satisfy LSB on LoongArch (unless LSB is revised or we do some unreasonable things to Glibc), as explained in the last comment of the upstream ticket and my change to LFS LoongArch.

And the upstream issue has been closed as invalid. IMO we should do the same now.