The Arm Linux binaries are incompatible with older systems

[Liviu Ionescu]

> On 24 Sep 2021, at 17:44, Johannes Hielscher <jhielscher at posteo.de> wrote:
> 
> 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?

To be honest, I include TL in my build environment only to build the manuals that accompany some GNU packages, like GCC.

I don't know what features are used by the GCC manuals, but so far building the PDFs for GCC 11 with TL 2018 seemed ok.


> 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.

My build platforms are 

- Ubuntu 12 for Intel Linux
- Ubuntu 16 for Arm linux
- macOS 10.13 for Intel Linux 
- (to be added soon) macOS 11 for Arm macOS.

The Ubuntu 12 is definitely too old, Ubuntu 16 may be able to build the current GCC manuals (and a few more other, but nothing bleeding edge), and installing TL on a headless macOS requires the install-tl script anyway.

Initially I used macOS 10.10, and I was able to install TL 2018 on all platforms.

Now I moved to macOS 10.13 and I can no longer install 2018 on it. Thus I moved to 2021; it worked for 10.13 and 11.x, but fails on older Ubuntus.

> 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 don't mind using TL 2018, but I can no longer install it on macOS 10.13.

>> 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.

Thank you, I'll try it, but this just adds some extra maintenance, since I have to do this with each new release.

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

It is, but Arm macOS started with 11.x. For Intel macOS the reference platform is macOS 10.13.

> ... Having TL binaries compiled
> against old glibc would be easiest for you, but it doesn't solve your
> problem, it just postpones it

No, it simply prevents me from using a more recent TL.

> ... 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

Support for RedHat Enterprise 7.7 ends in Aug. 2023. RH7 uses GLIBC 2.17.

Initially I planned to base my build environment on RH 7, but, for various reasons, this proved not realistic; the next available choice was Ubuntu 12, with GLIBC 2.15.

I produce binaries to be used in build and testing environments (like toolchains), and some of these testing environments are very conservative, I cannot force them to upgrade them.

I'll not wait till 2023, next year I'll drop support for RH 7 and move to GLIBC 2.23, available since Ubuntu 16.


So, thank you for your suggestion, but the choice for the system version is not mine; if I want my binaries to be useful in enterprise build environments, for now I have to keep compatibility with RH 7. 

FYI, the initial version of my binaries were built on CentOS 6, for the same reasons, compatibility wit RHE 6. I'm glad I got rid of CentOS 6, since it was a real pain in the rear.

> 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.

Yes, that's a good suggestion; I'll consider it for the future releases of my build environment.

> The contextgarden binaries, like kindly suggested by Michal, are a
> viable option for the moment.

The contextgarden binaries, if built for Debian 10 (GLIBC 2.28), will not run on Ubuntu 16.

---

So, as a conclusion, it would be great to provide Arm binaries based on a bit older platforms (similarly to Intel binaries).

If that is not possible, that's it.

For now I'll probably continue to use TL 2018. If, at a later moment, maintaining the TL binaries in my build environment (which is a free open-source project) will become too expensive, I'll simply drop support for building the embedded manuals. :-(


Thank you,

Liviu