Re: [discuss] Binary compatibility between Illumos distributions

[Peter Tribble <peter.tribble@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]

On Sun, Sep 29, 2024 at 8:26 AM Sad Clouds <cryintothebluesky@gmail.com>
wrote:

> Hi, if somebody is building binaries for Illumos x86_64 platform, is there
> a good binary compatibility between various Illumos distributions?
>

It's fairly good, with severe limitations.


> I know they may use different packaging systems for additional software,
> but if we assume the binaries are only linked with the base OS libraries
>

That's the first catch. Many applications end up being linked with
libraries that have a
relatively poor history of compatibility. And different distributions may
be shipping all sorts
of different versions. For example openssl might be 1.1.1 or 3.0 or 3.1 or
3.2. Interestingly,
while getting worse over time this is starting to become less of an issue
with runtimes
like go and rust where you often end with applications that are more
self-contained.


> and built with the system compiler,
>

That's the second catch. Different distributions have different compilers,
and may link
against libgcc_s and libcstd++. The basic advice there is that the binary
is only guaranteed
to run on a system with an equal or newer version of the gcc runtime (and
clang may
introduce other interesting constraints). There's an additional issue with
OpenIndiana
which ships multiple versions of the gcc runtime, hidden away.


> then can the same set of binaries be safely distributed for different
> distributions?
>

Again, within limitations.

And there's a third catch; there's a theoretical possibility that binaries
built on an LX
distribution might detect the presence of extra functionailty and implement
behaviour
based on that. In Tribblix I simply avoid this being an issue by building
all applications
on vanilla Tribblix rather than OmniTribblix, but the fact that the pkgsrc
binaries are built
on SmartOS and work everywhere indicates that this isn't much of a
practical issue,
and is a demonstration that compatibility does work (note that pkgsrc ships
its own
compilers and 3rd-party libraries, so avoiding the first two catches above).


> Also, Solaris used to have very good ABI backward compatibility, however
> Illumos distributions don't seem to use major/minor version numbers, but
> instead use a date string, or some unique release number. So how does one
> track incompatible ABI changes, etc?
>

What incompatible ABI changes?

The versioning of libc (which is the primary interfaces of interest - there
are relatively rare
changes to libsocket and libnsl, but the same rules apply) can be seen in
the source at

usr/src/lib/libc/port/mapfile-vers

so you can work out from the history there which interfaces were
introduced  in which
commits.

You can see the versioning history using 'pvs -vs'. Run it on libc and
you'll basically see
the same output as the mapfile-vers file in the source. Run it on any other
object
and you'll be able to see exactly which symbols are required, and which
library version
they correspond to. For example, on my system running 'pvs -vs' on bash and
the highest
version of libc that it requires is:

        libc.so.1 (ILLUMOS_0.29):
                getrandom;

So that my copy of bash will run on any illumos distribution that has
version 0.29 of
libc (which according to the git history came in with issue 9971 in
December 2018).
So, in this way, you can identify what the oldest compatible distribution
version is.

OK it may be stated in the release notes, but ideally it would need to be
> scripted, i.e. make file or config script would parse the OS version from
> the uname command and adjust the build variables. Is there some common
> versioning scheme across all Illumos distributions, maybe via a different
> command or version file in /etc?
>

So basically, not from anything other than the versioning of libc.so.

Ultimately, the solution is to find something adequately old and build on
that. I'm using
an old box with Tribblix m29 on it to generate my java builds, for example.
But java is
extremely precise and conservative in which library calls it uses. Other
software
(*cough* autoconf *cough*) may try and enable any functionality it finds on
the build system.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/Te614dba5c9d949ba-M7094879799212154dff5c6b4
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

[-- Attachment #2: Type: text/html, Size: 7185 bytes --]