ISO/IEC 23360-1-2:2021 is architecture-specific, so you cannot achieve compliance except with one of the described architectures.

I do not have access to the 2021 version, but unless they did substantial updates (that are not reflected on the LSB web site), it mostly applies to obsolete architectures no longer in use, and obsolete software versions.

ISO/IEC 23360-1-2:2021 is not architecture specific, it corresponds to [1] , which is a "Generic" part instead of a architecture-specific part; and the define of libutil.so.1 here is thus architecture-neutral, and at least could get implemented on new architectures.

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

If it's only about dlopen/dlsym, then a dummy link libutil.so.1 -> libc.so.6 should solve that.

Hi Florian,

ISO/IEC 23360 series, which are ISO versions of the modules of the Linux Standard Base, are actually publicly available at <https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html>. The life cycle status of the ISO/IEC 23360-1-1:2021 standard, "Linux Standard Base (LSB) Part 1-1: Common definitions" is "Published," meaning that it's a current ISO standard. Sections mentioned below are all from ISO/IEC 23360-1-1:2021.

Section 2.1 listed "libutil" as a library that "shall be available on a Linux Standard Base system, with the specified runtime name" "libutil.so.1".

It is indeed true that "a LSB conforming implementation is necessarily architecture specific", according to section 2.3. However, that doesn't prohibit architectures which are not mentioned by the specification to provide the interfaces specified by the generic LSB specifications (i.e., LoongArch may choose to conform to this specification if deemed appropriate).

Furthermore, section 2.4 points out that there're architecture-neutral applications which "shall conform only to the requirements of the generic LSB Core module specification (LSB Core - Generic)." If an architecture not named by the specifications choose not to provide the interfaces specified by the LSB, then that architecture will be no longer capable of running said applications relying the system interfaces prescribed by the specifications.

This means that the said architecture would not be able to become a LSB conforming implementation in the future, unless the generic LSB Core module specification conforms to the implementations seen in new architectures, such as LoongArch. This is really working in contradiction to the process of drafting and implementing specifications, rendering the specification invalid.

LSB is a standard about the whole system, where each interface may be provided by separate components.  The identity of these components is not part of the standard, and may change any time.

Also note that LSB also requires things like libncursesw.so.5, but in real life no recent distros install this thing in the base system, nor the building system of ncurses would build this thing by default.  To make libncursesw.so.5 you'll pass some strange command line options to ncurses configure script.

So if we go like ncurses we'll have some command line options to enable libutils.so.1.  But then why not just "echo 'static int __dummy;' | cc -x c - -o /usr/lib/libutils.so.1"?

Hi Andreas,

Section 2.1 of ISO/IEC 23360-1-1:2021 specifies "runtime names" for each library (or the so-called soname) that shall be available. Therefore "libutil.so.1" is actually part of the standard. 

It is true that the specifications might change over time. But in the spirit of the specification, would it not be best that we ensure that the implementations for new architectures conform to the specifications that are already in place?

This is an interface, not a component.

(In reply to Kexy Biscuit from comment #7)
> Hi Andreas,
> 
> Section 2.1 of ISO/IEC 23360-1-1:2021 specifies "runtime names" for each
> library (or the so-called soname) that shall be available. Therefore
> "libutil.so.1" is actually part of the standard. 

The point is LSB only says it shall be available, not saying "Glibc must provide it."

And I've already told how to create one with just an one-line command if you really need to satisfy LSB.

Similar to /lib64/ld-lsb-x86-64.so.3: LSB x86-64 requires it but Glibc won't create it.  If you need to satisfy LSB, create a symlink on your own.

LSB conformance is the duty of the system integrator.

(In reply to Kexy Biscuit from comment #7)
> Hi Andreas,
> 
> Section 2.1 of ISO/IEC 23360-1-1:2021 specifies "runtime names" for each
> library (or the so-called soname) that shall be available. Therefore
> "libutil.so.1" is actually part of the standard. 
> 
> It is true that the specifications might change over time. But in the spirit
> of the specification, would it not be best that we ensure that the
> implementations for new architectures conform to the specifications that are
> already in place?

Those sonames are expected to be architecture-specific because they are part of the ABI, and the ABI is architecture-specific. They should not be part of the architecture-independent part of any standard. It's even more obvious with the symbol versions that the supposedly-generic part of LSB 5.0 specifies for epoll_create, __chk_fail and many other functions. By the time LSB 5.0 was released in 2015, there already was considerable baseline variance among architectures, resulting in symbol versions varying across architectures. All this would be easily explained if “generic” in the LSB sense means “common to the LSB-supported architectures”. AArch64, LoongArch, RISC-V and many others are not among them.

We could have easily explained all this if anyone working on re-conforming the ISO standard had asked us for comments. Specifically for libutil, even back then, it was pretty clear that some of the functions defined in libutil were obsolete, likely to be removed, and that there was a distinct possibility hat libutil as a whole would be removed as well.