The Arm Linux binaries are incompatible with older systems

[Liviu Ionescu]

> On 24 Sep 2021, at 00:19, Michal Vlasák <lahcim8 at gmail.com> wrote:
> 
> ... a new builder for the ConTeXt
> build farm (https://build.contextgarden.net/). As the build farm also
> builds whole TeX Live, theoretically you could use those binaries (IIRC
> the TeX Live installer allows custom binaries). But those are from the
> development versions -- though I think that you can safely use the
> "luatex" binary from there:
> 
>    https://dl.contextgarden.net/build/texlive/aarch64-linux.tar.xz

Thank you, but, if I got it right, these binaries are also built on a Debian 10, which uses the same GLIBC 2.28 version.

For my build environment I did a research on how GLIBC versions were used during time for various distributions, and I ended with a page to summarise this:

- https://github.com/xpack/xpack-build-box#distro-versions

>From my understanding, the oldest 64-bit Arm systems used GLIBC 2.23 (Ubuntu 16) and 2.24 (Debian 9).

For various practical reasons (like more recent updates available), for my build environment I decided to use Ubuntu 16, which, in my opinion, should cover the vast majority of existing Arm Linux machines.

> Anyways, the usual TeX Live binaries need a rebuild against older glibc
> (by e.g. building on an older Linux distro release).

Agree. My suggestion is to go back as far as GLIBC 2.23.

> ... But maybe the binaries can be
> built on the ConTeXt build farm by Mojca, considering that it is already
> set up?

Yes, that would be a solution, but he should add Ubuntu 16 runners instead of the existing Debian 10 runners. 

But why not build the LUA binaries on the same machine where the other binaries are built?

Another option would be to have a choice (like a command line option for the install script) to compile these binaries locally from sources.

> PS: The only GLIBC_2.28 symbol in luatex seems to be fcntl64. Which is
> there, because the Lua filesystem (LFS) library used by LuaTeX supports
> long files by default. There is a check for LFS_DO_NOT_USE_LARGE_FILE,
> though it's probably not wise to go that route.

You mean that building the binaries on an older GLIBC will not use this feature, because this system call was added in 2.28?

---

Anyway, a new release with these binaries fixed will most probably take more time that I can afford to wait.

So, for my specific use case, is there any hack that I can try in order to install 2021 in my build environment (Ubuntu 16 for Arm and Ubuntu 12 for Intel)?

I think I can live well enough without LUA support, so my first choice would be to remove it from the installation. Currently I pass "medium" to the install script. Is there any way to pass something like "medium without lua"?

If this is not reasonable, the second choice would be to build the binaries locally and patch the install script to skip the copy of the available binaries.

If none of these is reasonable, I'll probably have to stick to 2018 for this release of my build environment and hope that the future TeX Live release will be fixed.


Regards,

Liviu