The Arm Linux binaries are incompatible with older systems
ilg at livius.net
Fri Sep 24 18:08:47 CEST 2021
> 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 , the SVN READMEs  and/or CI workflow files
> ). 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. :-(
More information about the tex-live