The Arm Linux binaries are incompatible with older systems

[Johannes Hielscher]

Am Thu, 23 Sep 2021 23:21:59 +0300
schrieb Liviu Ionescu <ilg at livius.net>:

> For several years I used TeX Live 2018 in a cross-platform build
> environment (Docker based for Intel & Arm Linux, a separate folder on
> macOS).
> 
> When I tried to upgrade all platforms to TeX Live 2021, the
> `install-tl` script failed in the Arm Docker images. 
> 
> After several investigations, I found out that the LUA binaries are
> compiled agains GLIBC_2.28 (probably on a Raspberry Pi):
> 

> For compatibility with older systems, my build environment is based
> on Ubuntu 16, which uses an older GLIBC (2.23), and thus the system
> loader cannot load the more recent binaries:

When compatibility with older systems is an issue that blocks you from
upgrading your operating system baseline, does this mean that the
content for which you provide TL binaries does also not rely on
recent/bleeding-edge developments on the TeX side?

The kernel of TeX and most of the popular macro sets are slow-moving
these days. And even in case of changes (bug fixes, etc.), it appears
to me that the TeXLive packages provided in the repositories of
your Linux distribution (DEBs via apt) should be first choice in any
case, IMHO.
I don't see a point in clinging to a Linux platform for half a decade
(or longer), but then pull in the newest and shiniest TeXLive with all
its subtle changes on a yearly basis.

I settled to do my builds (aarch64-linux) on Debian oldstable (buster
atm) to avoid the worst incompatibilities with people who haven't
managed to upgrade their boxes for the last about two years. I deem
this a reasonable compromise on a “young” platform like AArch64.

> 
> So, for now, unless you have a better suggestion (like selectively
> disabling the LUA packages?),
Yes, you can run install-tl on another machine, select a custom
scheme (that excludes LuaTeX), save via 'P', and feed the resulting
texlive.profile into your Dockerfile.

> I have to stick with the 2018
> distribution for all platforms; but since the 2018 distribution can
> no longer be installed on more recent macOS releases, for macOS I'm
> forced to upgrade to 2021, resulting an inconsistent environment,
> which usually asks for trouble.

Isn't old Ubuntu + new macOS an inconsistent environment in any case?

> 
> It would be great to rebuild the Arm LUA binaries (64/32-bit) on an
> Ubuntu 16 (this can be easily done with existing Docker images)

I personally am very reluctant to invest into containerisation, just to
make it superficially easier to prolong the life of obsolete
infrastructure (Ubuntu 16.04LTS is apparently only the tip of the
iceberg). It is my conviction that it is an *advantage* of free
software that things like glibc or the Linux kernel periodically break
binary compatibility, to make it more difficult for code rot or
questionable “works for me, can't be bad” hacks to creep into complex
systems.


> In fact the
> world did not start with the Raspberry Pi revolution.
FWIW, said Raspberry Pi “revolution” is not a great measure of progress
at all. Still stuck to 32-bit instructions on hardware that speaks
64 bits since 2016.

> 
> 
> Regards,
> 
> Liviu
>  


Please don't get me wrong. I don't want to be unhelpful, I'm just under
the impression that you are facing a problem that lies deeper than just
the inconvenient progress of the glibc ABI. Having TL binaries compiled
against old glibc would be easiest for you, but it doesn't solve your
problem, it just postpones it (nicely wrapped into the SPOF Y2038-class
issue of Dockerification). I strongly suggest that you consider other
possibilities (like upgrading whatever keeps you from dropping Ubuntu
16.04LTS, or becoming more insistent towards those who are behind
schedule at keeping pace with modern OS development – I wonder why
this works for macOS but not for Linux?), before you rely on volunteers
to build binaries on outdated platforms for an indefinite time into the
future.

By the way, have you tried to build TeXLive by yourself? The build
is not complicated, especially if you --disable-native-texlive-build
(check the wrap-up [0], the SVN READMEs [1] and/or CI workflow files
[2]). It takes less than an hour on modern RPi/SBC hardware.

The contextgarden binaries, like kindly suggested by Michal, are a
viable option for the moment. Though, clarify with Mojca, Hans etc.
first, if/how long they intend to keep this service online for
non-interactive productivity purposes of third parties.


Best,
Johannes


[0]
http://tug.org/texlive/build.html
[1]
http://tug.org/svn/texlive/trunk/Build/source/README.2building?view=markup
[2]
http://tug.org/svn/texlive/trunk/Build/source/.github/workflows/main.yml?view=markup