Index of /pub/texlive-utah-2022

[ICO]NameLast modifiedSize

[PARENTDIR]Parent Directory  -
[DIR]Images/2022-04-05 08:27 -
[TXT]README.html2022-02-28 06:14 167K
[   ]README.sok2021-04-21 14:50 3.6K
[   ]README.texlive2021-01-06 08:38 6.8K
[   ]SYS.texlive-2022.csh2022-01-27 10:43 8.2K
[   ]SYS.texlive-2022.sh2022-01-27 10:43 7.2K
[DIR]bin/2022-02-26 16:27 -
[   ]build-asymptote.sh2022-01-22 08:19 7.4K
[   ]build-texlive-2022.sh2022-01-22 18:16 61K
[   ]make-texlive-binary-distributions.sh2021-01-19 06:37 1.6K
[   ]make-texlive-snapshot-2022.sh2022-01-05 14:57 2.0K
[   ]show-file-counts.sh2022-01-13 06:48 2.4K
[   ]show-lib-deps.sh2022-01-13 06:52 1.4K
[   ]show-texlive-libs.sh2022-01-13 06:52 2.1K
[   ]update-texlive-2022.sh2022-01-05 15:23 5.3K


                     

TEX Live 2022 early access

Original version: Thu Jan 6 10:33:20 2022
Last updates: ... Mon Feb 28 06:14:07 2022
Current time in Salt Lake City, Utah, USA: Friday, 12-Aug-2022 03:00:24 MDT

This is the latest in an series of annual documents describing work at Utah on building TeX Live software packages: for earlier reports, follow these links: 2016, 2017, 2018, 2019, 2020. and 2021.

Here are links to later major sections in this document:

This directory contains files created in support of building and using a pre-release of the TeX Live 2022 distribution. The official release is expected in April 2022, and should be available on DVD in mid-summer 2022; you can download it electronically here. Please note that if you install it from either of those sources, you should first choose a suitable mirror, and then run the update procedure described later in this document. The TeX Live package repository is actively maintained, and you should expect that several hundred packages are updated each month.

Your first task is to learn how to mount an ISO image on your platform. On many desktops, simply selecting its icon in a File Manager tool does the job. On others, you might have to mount the image (usually as an administrator), such as with this command on most Linux flavors:

    # mount -o ro /path/to/your/copy/of/texcol2022.iso /mnt

Details of how to mount an ISO image on many operating systems are described here.

The top-level directory of the DVD image contains README and index.xx.html files (in English, French, and German) that should help guide your selection and installation procedure. For example, Unix users can run the script texlive/install-tl, and Windows users, the script texlive/install-tl-windows.bat. In either case, brief answers to a few questions about your local preferences get the installation started. The rest is automatic, and should complete in less than an hour. See below for resource requirements and how to choose a TeX Live package repository mirror near you.

When installation completes, you should unmount the image through your File Manager, or with an administrator command like this:

    # umount /mnt

After a successful installation, the ISO image is then no longer needed, and can be deleted if disk space is limited. Copies of the image remain on numerous TeX Live mirror sites for years, so you can always download it again if needed.

There are more details about the installation process here.

A test lab at this site has hundreds of flavors of Unix on some of which TeX Live builds are attempted, and the scripts named *.*sh in this directory are those used by the local developer.

The intent of the build-texlive-2022.sh script is that it should setup the build environment on each platform, and then run the internal Build script to carry out the build. We have found it necessary on many platforms to carefully control the search path and environment variables at the start of a TeX Live build, and to avoid use of installation locations that are owned by the vendor package system. See elsewhere for an explanation of why we scrupulously avoid the GNU default prefix of /usr/local on new systems.

The scripts in this directory are likely to change during the spring build season for TeX Live 2022 as more platforms are successfully supported.

Note: In sharp contrast to previous years, certain non-TeXware libraries required by some of the TeX Live 2018, 2019, 2020, 2021, and 2022 binary executable programs now mandate compiler support for more recent versions of ISO Standard C++, and such compilers are unavailable for many older systems. As a result, the number of platforms for which the code can be built and run has been noticeably reduced. Unless your computer and operating system are fairly new, the last release that you may be able to run until you do an operating system, and possibly, hardware, upgrade is TeX Live 2017.

If you control your own hardware, or have benevolent computer management, and you really need the latest TeX Live, then a good solution may be to create a virtual machine (VM) running a recent O/S release. There are several free, or no-cost, or low-cost, virtualization technology solutions, including bhyve, Hyper-V, KVM, QEMU, virt-manager, OVirt, Parallels, VirtualBox, VMware Workstation Player, and Xen, and every modern operating system supports one or more of those, although generally, at most one can be installed at a given time.

One of the easiest for a new user is VirtualBox, and it requires no special privileges to create and run a virtual machine. At the Utah test lab, we generally allocate a new VM one CPU, 1GB to 4GB DRAM memory, and 80GB of virtual disk storage. For the single purpose of running TeX Live, a 25GB disk would be ample. The VM treats CPU, memory, and disk as expandable resources up to their declared size, so if an initial installation needs only 4GB of disk space, that is all that the underlying host needs to provide. If the assigned memory size is suboptimal, just shut down the VM, change the memory size in the VM management GUI, and reboot the VM. In our experience, setting up a new VM takes about 15 minutes, and modern O/Ses have management GUIs that make user account setup and software package installation easy for novices.

Most commercial cloud services supply a choice of preconfigured virtual machines, but you must pay a small monthly fee for CPUs and disk storage. The advantage is that the service provider does most of the work for you, including VM configuration and backup, and in return, you can access and control your personal cloud VM from anywhere in the world where you have an Internet connection.

As of 26 February 2022, the following builds have been (mostly) successful at Utah:

    % show-file-counts.sh
    462      alpha-debian11
    470      amd64-freebsd104
    468      amd64-freebsd11-gcc
    468      amd64-freebsd123
    463      amd64-freebsd13-gcc
    468      amd64-freebsd14-gcc
    468      amd64-ghostbsd2111
    468      amd64-ghostbsd2201
    468      amd64-hardenedbsd13
    468      amd64-hardenedbsd14
    468      amd64-netbsd100
    463      amd64-openbsd70
    465      arm64-debian11
    469      arm64-freebsd13
    468      armv7l-archlinux
    468      i686-centos7
    463      i686-void
    464      i86pc-openindiana
    457      m68k-debian11
    462      ppc64be-centos7
    457      ppc64le-centos8
    457      ppc64le-debian10
    457      s390x-debian11
    457      s390x-ubuntu2004
    462      sparc64-debian11
    470      x86_64-absolute15
    468      x86_64-almalinux
    468      x86_64-alpine313
    468      x86_64-alpine315
    470      x86_64-archlabs
    468      x86_64-archlinux
    468      x86_64-artix
    463      x86_64-blackarch
    470      x86_64-centos7
    468      x86_64-centos8-stream
    468      x86_64-centos9
    468      x86_64-debian12
    468      x86_64-devuan31
    468      x86_64-devuan40
    468      x86_64-dragonflybsd59
    468      x86_64-dragonflybsd601
    468      x86_64-dragonflybsd621
    468      x86_64-eurolinux8
    468      x86_64-fedora34
    468      x86_64-fedora36
    468      x86_64-mint203
    468      x86_64-navy
    468      x86_64-opensuse154
    468      x86_64-opensusetw
    468      x86_64-redcore2102
    468      x86_64-rocky83
    468      x86_64-slackel75
    470      x86_64-slackware15
    468      x86_64-springdale83
    470      x86_64-ubuntu2004
    469      x86_64-ubuntu2204
    468      x86_64-void
    468      x86_64-vzlinux
    470      x86_64-zenwalk15

    Total: 59 systems

    Missing binaries [compared to x86_64-centos7]:

    alpha-debian11                  : citeproc luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc twill
    amd64-freebsd11-gcc             : citeproc twill
    amd64-freebsd123                : citeproc twill
    amd64-freebsd13-gcc             : citeproc tex2xindy texindy twill xindy xindy.mem xindy.run
    amd64-freebsd14-gcc             : citeproc twill
    amd64-ghostbsd2111              : citeproc twill
    amd64-ghostbsd2201              : citeproc twill
    amd64-hardenedbsd13             : citeproc twill
    amd64-hardenedbsd14             : citeproc twill
    amd64-netbsd100                 : citeproc twill
    amd64-openbsd70                 : asy citeproc luajittex mfluajit mfluajit-nowin twill xasy
    arm64-debian11                  : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc
    arm64-freebsd13                 : asy xasy
    armv7l-archlinux                : citeproc twill
    i686-centos7                    : citeproc twill
    i686-void                       : citeproc tex2xindy texindy twill xindy xindy.mem xindy.run
    i86pc-openindiana               : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc
    m68k-debian11                   : citeproc luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc twill xindy xindy.mem xindy.run
    ppc64be-centos7                 : citeproc luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc twill
    ppc64le-centos8                 : citeproc luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc twill xindy xindy.mem xindy.run
    ppc64le-debian10                : citeproc luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc twill xindy xindy.mem xindy.run
    s390x-debian11                  : citeproc luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc twill xindy xindy.mem xindy.run
    s390x-ubuntu2004                : citeproc luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc twill xindy xindy.mem xindy.run
    sparc64-debian11                : citeproc luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc twill
    x86_64-almalinux                : citeproc twill
    x86_64-alpine313                : citeproc twill
    x86_64-alpine315                : citeproc twill
    x86_64-archlinux                : citeproc twill
    x86_64-artix                    : citeproc twill
    x86_64-blackarch                : citeproc tex2xindy texindy twill xindy xindy.mem xindy.run
    x86_64-centos8-stream           : citeproc twill
    x86_64-centos9                  : citeproc twill
    x86_64-debian12                 : citeproc twill
    x86_64-devuan31                 : citeproc twill
    x86_64-devuan40                 : citeproc twill
    x86_64-dragonflybsd59           : citeproc twill
    x86_64-dragonflybsd601          : citeproc twill
    x86_64-dragonflybsd621          : citeproc twill
    x86_64-eurolinux8               : citeproc twill
    x86_64-fedora34                 : citeproc twill
    x86_64-fedora36                 : citeproc twill
    x86_64-mint203                  : citeproc twill
    x86_64-navy                     : citeproc twill
    x86_64-opensuse154              : citeproc twill
    x86_64-opensusetw               : citeproc twill
    x86_64-redcore2102              : citeproc twill
    x86_64-rocky83                  : citeproc twill
    x86_64-slackel75                : citeproc twill
    x86_64-springdale83             : citeproc twill
    x86_64-ubuntu2204               : citeproc
    x86_64-void                     : citeproc twill
    x86_64-vzlinux                  : citeproc twill

The first column in the first table is the number of installed executables, and the second column is the CPU architecture, base operating system, distribution, and optional version.

Of those directories, the following are part of the pre-test installation (described below):

    aarch64-linux  i386-cygwin   i386-solaris      x86_64-darwinlegacy
    amd64-freebsd  i386-freebsd  universal-darwin  x86_64-linux
    amd64-netbsd   i386-linux    win32             x86_64-linuxmusl
    armhf-linux    i386-netbsd   x86_64-cygwin     x86_64-solaris

Most of the others have been built at the University of Utah, almost entirely in facilities of the Department of Mathematics, and on my personal home VM cluster running with VirtManager and QEMU on top of Ubuntu 20.04. Several of those VMs emulate other CPU architectures.

Builds that lack the *xindy* files are on systems for which clisp is absent from the operating system package repositories, or has not been installed from the repositories, or has not yet been successfully built and installed locally from source code. That deficiency may be remedied if time permits.

Although some of the builds on FreeBSD and GNU/Linux systems appear to duplicate the contents of i386-freebsd, i386-linux, amd64-freebsd, and x86_64-linux, they serve two purposes: (1) demonstration of the possibility of independent builds of TeX Live at other sites and on different O/S distributions, and (2) builds on bleeding-edge O/S releases may benefit from new and improved compiler technology, and newer system libraries.

Arch Linux (arch), Artix Linux, BlackArch, ClearLinux, CentOS Stream, Fedora Rawhide (fedorarh), GUIX, Hyperbola, Kaisen, Kali, Kaos, PCLinuxOS (pclinuxos), Peppermint OS (from 20222), openSUSE Jump, openSUSE Tumbleweed, Parabola, Solus, Trident, TrueOS (trueos1806), Ubuntu RR (ubuntu-rr), and Void Linux do not have version numbers: they use a rolling-update model, and once updates have run, and if needed, the systems have been rebooted, they are at the latest available software levels.

It may also be of interest to record the library dependencies of all of the executables in one of the binary directories:

    % show-lib-deps.sh $prefix/texlive/2022/bin/amd64-freebsd130/
    Library dependencies of TeX Live executables in amd64-freebsd130:

    libGL-NVIDIA                 asy
    libICE                       asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin xdvi-xaw
    libSM                        inimf mf mflua mflua-nowin mfluajit mfluajit-nowin xdvi-xaw
    libX11                       asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin pdfclose pdfopen xdvi-xaw
    libXau                       asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin pdfclose pdfopen xdvi-xaw
    libXaw                       xdvi-xaw
    libXdmcp                     asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin pdfclose pdfopen xdvi-xaw
    libXext                      asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin xdvi-xaw
    libXi                        asy
    libXmu                       xdvi-xaw
    libXpm                       xdvi-xaw
    libXrandr                    asy
    libXrender                   asy
    libXt                        xdvi-xaw
    libXxf86vm                   asy
    libbz2                       xelatex xelatex-dev xetex
    libc                         afm2pl afm2tfm aleph amstex asy autosp axohelp bbox bg5conv bibtex bibtex8 bibtexu cef5conv cefconv cefsconv cfftot1 chkdvifont chktex cslatex csplain ctangle ctie ctwill ctwill-refsort ctwill-twinx cweave detex devnag disdvi dt2dv dv2dt dvi2tty dvibook dviconcat dvicopy dvidvi dvigif dvilj dvilj2p dvilj4 dvilj4l dvilj6 dvilualatex dvilualatex-dev dviluatex dvipdfm dvipdfmx dvipng dvipos dvips dviselect dvispc dvisvgm dvitodvi dvitomp dvitype ebb eplain epsffit eptex etex euptex extconv extractbb gftodvi gftopk gftype gregorio gsftopk hbf2gf inimf initex jadetex kpseaccess kpsereadlink kpsestat kpsewhich lacheck lamed latex latex-dev lollipop luacsplain luahbtex luajithbtex luajittex lualatex lualatex-dev luatex mag makeindex makejvf mendex mex mf mf-nowin mflua mflua-nowin mfluajit mfluajit-nowin mfplain mft mllatex mltex mmafm mmpfb mpost msxlint odvicopy odvitype ofm2opl omfonts opl2ofm otangle otfinfo otftotfm otp2ocp outocp ovf2ovp ovp2ovf patgen pbibtex pdfclose pdfcslatex pdfcsplain pdfetex pdfjadetex pdflatex pdflatex-dev pdfmex pdfopen pdftex pdftosrc pdfxmltex pdvitomp pdvitype pfb2pfa pk2bm pktogf pktype platex platex-dev pltotf pmpost pmxab pooltype ppltotf prepmx ps2pk psbook psnup psresize psselect pstops ptex ptftopl r-mpost r-pmpost r-upmpost scor2prt sjisconv synctex t1ascii t1asm t1binary t1disasm t1dotlessj t1lint t1mac t1rawafm t1reencode t1testpage t1unmac t4ht tangle teckit_compile tex tex2aspc tex2xindy tex4ht texlua texluac texluajit texluajitc texsis tftopl tie ttf2afm ttf2pk ttf2tfm ttfdump ttftotype42 upbibtex updvitomp updvitype uplatex uplatex-dev upmendex upmpost uppltotf uptex uptftopl utf8mex vftovp vlna vptovf weave wofm2opl wopl2ofm wovf2ovp wovp2ovf xdvi-xaw xdvipdfmx xelatex xelatex-dev xetex xindy.run xmltex
    libcrypt                     xindy.run
    libexpat                     xelatex xelatex-dev xetex
    libffcall                    xindy.run
    libfftw3                     asy
    libfontconfig                xelatex xelatex-dev xetex
    libfreetype                  xelatex xelatex-dev xetex
    libgcc_s                     asy luajittex mfluajit mfluajit-nowin
    libglut                      asy
    libgsl                       asy
    libgslcblas                  asy
    libintl                      xdvi-xaw xindy.run
    libm                         afm2pl afm2tfm aleph amstex asy autosp axohelp bbox bg5conv bibtex bibtex8 bibtexu cef5conv cefconv cefsconv cfftot1 chkdvifont chktex cslatex csplain ctangle ctie ctwill ctwill-refsort ctwill-twinx cweave detex devnag disdvi dt2dv dv2dt dvi2tty dvibook dviconcat dvicopy dvidvi dvigif dvilj dvilj2p dvilj4 dvilj4l dvilj6 dvilualatex dvilualatex-dev dviluatex dvipdfm dvipdfmx dvipng dvipos dvips dviselect dvispc dvisvgm dvitodvi dvitomp dvitype ebb eplain epsffit eptex etex euptex extconv extractbb gftodvi gftopk gftype gregorio gsftopk hbf2gf inimf initex jadetex kpseaccess kpsereadlink kpsestat kpsewhich lacheck lamed latex latex-dev lollipop luacsplain luahbtex luajithbtex luajittex lualatex lualatex-dev luatex mag makeindex makejvf mendex mex mf mf-nowin mflua mflua-nowin mfluajit mfluajit-nowin mfplain mft mllatex mltex mmafm mmpfb mpost msxlint odvicopy odvitype ofm2opl omfonts opl2ofm otangle otfinfo otftotfm otp2ocp outocp ovf2ovp ovp2ovf patgen pbibtex pdfclose pdfcslatex pdfcsplain pdfetex pdfjadetex pdflatex pdflatex-dev pdfmex pdfopen pdftex pdftosrc pdfxmltex pdvitomp pdvitype pfb2pfa pk2bm pktogf pktype platex platex-dev pltotf pmpost pmxab pooltype ppltotf prepmx ps2pk psbook psnup psresize psselect pstops ptex ptftopl r-mpost r-pmpost r-upmpost scor2prt sjisconv synctex t1ascii t1asm t1binary t1disasm t1dotlessj t1lint t1mac t1rawafm t1reencode t1testpage t1unmac t4ht tangle teckit_compile tex tex2aspc tex2xindy tex4ht texlua texluac texluajit texluajitc texsis tftopl tie ttf2afm ttf2pk ttf2tfm ttfdump ttftotype42 upbibtex updvitomp updvitype uplatex uplatex-dev upmendex upmpost uppltotf uptex uptftopl utf8mex vftovp vlna vptovf weave wofm2opl wopl2ofm wovf2ovp wovp2ovf xdvi-xaw xdvipdfmx xelatex xelatex-dev xetex xindy.run xmltex
    libncurses                   asy xindy.run
    libncursesw                  asy xindy.run
    libnvidia-glcore             asy
    libnvidia-tls                asy
    libreadline                  asy xindy.run
    librt                        asy
    libsigsegv                   asy xindy.run
    libthr                       asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin pdfclose pdfopen upmendex xdvi-xaw xelatex xelatex-dev xetex
    libunistring                 xindy.run
    libusbhid                    asy
    libxcb                       asy inimf mf mflua mflua-nowin mfluajit mfluajit-nowin pdfclose pdfopen xdvi-xaw
    libz                         asy xelatex xelatex-dev xetex

xz-compressed tar files for each of the binary trees can be found here . They are about 60% of the size of corresponding gz-compressed files, both at maximal compression level -9. They would normally be unpacked in the directory path /path/to/texlive/2022/bin. After installing them, it is likely necessary to update the TeX preloaded memory-image files, *.fmt, by running the command ./fmtutil-sys --all in the just-unpacked directory. Those files are TeX-Live-release dependent, but platform-independent, so if you unpack multiple binary trees that are shared across different systems, you only need to regenerate them once.

The binary format files that contain precompiled macros for various engines based on TeX sometimes contain settings for the local paper size, notably, those engines that can produce PDF output. Therefore, before you run fmtutil-sys, run whichever of these is suitable for your site:

    % tlmgr paper a4            # for European A4 paper (210mm × 297mm)
    % tlmgr paper letter        # for US letter A paper (8.5in × 11in)

For more on the problems of configuring a default paper size for TeXware, see the document section Page layout and document printing.

TeX Live executables can often be shared with O/S releases of higher levels, and binaries for the oldest GNU/Linux release have a good chance of running on other GNU/Linux distributions for the same CPU family. That works as long as Linux kernel and system library versions are upward compatible. Thus, a CentOS 6 binary can likely run on CentOS 7, CentOS 8 and CentOS 9, but also on Alma, Debian, Devuan, EuroLinux, Navy, openSUSE, Red Hat, Rocky, Scientific Linux, Springdale, Ubuntu, VZLinux, and hundreds of other Linux distributions. Similarly, Solaris 10 binaries run just fine on Solaris 11. FreeBSD binaries are often usable on ArisbluBSD, ClonOS, FreeNAS, FuryBSD, GhostBSD, HardenedBSD, KFreeBSD, MidnightBSD, NomadBSD, OPNsense, PacBSD, PC-BSD, Trident, and TrueOS.

Once an installation is complete for a given platform, a user can switch to it by executing one of these scripts:

    ### assume prefix=/usr/local (but trivially changeable at each site)

    ### csh and tcsh login shells
    source $prefix/skel/SYS.texlive-2022.csh

    ### ash, bash, dash, ksh, pdksh, sh, and sh login shells
    ### (POSIX-compliant, or supersets thereof)
    . $prefix/skel/SYS.texlive-2022.sh

Those scripts redefine certain TeXware environment values to new ones suitable for use with TeX Live, and they reset the PATH to put the 2022 release first, ahead of any local, older TeX Live, or vendor-supplied installations of TeX.


Resource requirements

An installed TeX Live 2022 tree with all available packages, and binaries for one O/S architecture, requires about 13GB of disk space. It contains about 15_000 directories and 216_000 files. Smaller storage totals are possible with the installer programs in the official TeX Live 2022 DVD image, which allow you to choose subsets for your local installation.

Building TeX Live 2022 requires primarily source code, rather than macro packages and fonts: about 1.5GB of storage suffices on most platforms.

Fortunately, computer storage costs continue to drop. In early 2021 on the US market, spinning magnetic disks cost about US$20 per terabyte, and solid-state disks (SSDs) cost about US$85 per terabyte. Thus, storage of a full TeX Live 2022 tree costs between US$0.25 and US$1.10, similar to that for stamps on a traditional postal letter, and less than a typical cafe beverage.

The economic realities of the computer market today, and knowledge of resource growth from computer history, suggest that it is better to spend money on more, and faster, storage, internal memory (DRAM), and more CPU cores, than it is to pay premium prices for higher CPU clock speeds. Most personal computers, from mobile devices to laptops to desktops, are idle much of the time.


Choosing a TeX Live repository mirror

The master TeX Live repository is located in Paris, France, but there may be a repository mirror with higher data transfer rates that is closer to you.

For example, to change your default repository to the North American master mirror in Utah, run this command:

    % tlmgr option repository http://ctan.math.utah.edu/tex-archive/systems/texlive/tlnet

To switch back to the Paris master site, run this command:

    % tlmgr option repository http://mirror.ctan.org/systems/texlive/tlnet

That chooses a mirror site that is `near' you. It is likely to differ on successive updates, due to network traffic and machine load.

Once a repository has been chosen, your TeX Live installation remembers the setting, so the sample commands above are likely to be needed only once a year, unless you travel a lot with TeX Live on a mobile device, in which case the Paris master is likely your best choice.

If you have reason to suspect that your chosen TeX Live mirror is out of date, check its status at the CTAN monitoring site.

You can find a long list of CTAN mirror sites here.


Installing the TeX Live 2022 pre-test

The official description of installing the TeX Live 2022 pre-test is found here. However, because that document doesn't show explicit examples, it may leave the human puzzled as to which repository to choose. I recorded these steps that produce a working installation using the Utah mirror:

    ### Move to a temporary directory
    $ cd /path/to/suitable/temporary/directory

    ### Fetch the small (6MB) installer bundle
    $ wget http://www.math.utah.edu/pub/texlive/tlpretest/install-tl-unx.tar.gz

    ### If wget is not available on your system, use
    $ curl http://www.math.utah.edu/pub/texlive/tlpretest/install-tl-unx.tar.gz > install-tl-unx.tar.gz

    ### If curl is not available on your system, download the URL with any Web browser

    ### Unpack the installer bundle
    $ tar xf install-tl-unx.tar.gz

    ### Move to the just-unpacked installer directory
    ### [WARNING: the year-month-day numeric suffix changes daily]
    $ cd install-tl-20220226

    ### Start the work, using the Utah mirror
    $ ./install-tl -repository http://www.math.utah.edu/pub/texlive/tlpretest/

The text-mode installer asks a few questions. I selected all binary platforms (because our servers supply them to numerous clients of varying operating systems and CPU types), picked the full installation scheme, provided the location of the installation tree, chose a suitable local paper type, and then typed I to begin the automatic installation of 7337 packages. That step took 42 minutes on a physical machine, or about 170 packages per minute. The installation creates about 15_500 subdirectories and 216_000 files.

The newly installed tree takes almost 11GB of filesystem space, with executables for 16 platforms in the bin subdirectory. That subdirectory takes 2.9GB of space, so a typical installation with just one platform directory would need about 8GB of space. However, the space requirements increase with each subsequent update with tlmgr, because it normally saves previous versions, to allow package rollback if a problem is detected.

To verify the above experience, the next day, I redid the installation on a virtual machine running FreeBSD 13 with ZFS. This time, I selected just the default platform package. There were 3978 packages installed in 36 minutes, or 110 packages per minute. Packages per minute rates on other installations for the 2020 installation are:


Updating your TeX Live 2022 pre-test installation

Every few days, I update my TeX Live 2022 pre-test installation tree like this on my CentOS 7 workstation:

    $ PATH=/path/to/texlive/2022/bin/x86_64-linux-centos-7:$PATH
    $ export PATH

    ### Update TeX Live Manager itself (this usually does nothing)
    $ tlmgr update --self

    ### Update TeX Live 2022 tree
    $ tlmgr update --all

Obviously, those commands are good candidates for hiding in a wrapper script. If you add an invocation of that script to your crontab(1) file, it then runs automatically at intervals that you specify in that file, and sends its output in e-mail to you.

Here is a sample crontab file entry that does just that, dispensing with a wrapper script, and running the update every Sunday morning at 3:15am local time (the #-initiated comments are part of my crontab file as a reminder of the field order and meaning):

    # 00-59 00-23 01-31 01-12 0-6(0=Sunday)
    # mm    hh    dd    mon   weekday       command
      15     3    *     *     0             ( PATH=/path/to/texlive/2022/bin/x86_64-linux:/bin:/usr/bin ; export PATH ; tlmgr update --self ; tlmgr update --all )

Change the weekday field from 0 to * to make the job run daily. Change it to 1,3,5 to run it Monday, Wednesday, and Friday. Such jobs are usually best run at off-peak hours at both your site, and the repository site. Our site in Utah is on US Mountain Time (UTC/GMT - 6 hours in summer, UTC/GMT - 7 hours in winter). The TUG master site in Paris, France, is on Central European Time (UTC/GMT + 2 hours in summer, UTC/GMT + 1 hour in winter).

As of your last browser refresh of this Web page, the time in Salt Lake City is Friday, 12-Aug-2022 03:00:24 MDT .

The script that we use at Utah for TeX Live updates is available here. It contains a comment header that includes reminders of how to select the repository during both pre-test and post-release times.


Build problems and other remarks for TeX Live 2022

Donald Knuth's TeX and METAFONT, and their associated TeXware and MFware programs and data files, have proven extraordinarily robust over more than 40 years of use, and have been ported to most commercially important machine architectures (operating systems and CPUs), from mobile devices to supercomputers. Their original code is in Web, a literate-programming language that can be processed by tangle and weave to produce a Pascal program file and a TeX file that documents the software.

Pascal no longer enjoys the popularity that it did when Donald Knuth chose it as his second implementation language, and C is now the most widely available language that continues to be used for much of the world's software. Thus, for about 30 years, the Pascal source has been translated automatically to the C language by a special utility.

Most other software related to TeX and Metafont written since then has been in C, C++, Fortran, Java, and Common Lisp, in the Unix/POSIX shell, sh, and in scripting languages like awk, javascript, lua, perl, and python. It is rare to find a system where TeX and METAFONT themselves cannot be built.

A modern TeX Live distribution continues much more than just TeX and METAFONT. On top of those two programs, each about 20_000 lines of Pascal, stands a TeX Live source tree that, after a build has completed, has about 2375 directories, 29_650 files, 270 Makefiles, and 85 GNU-style configure scripts. The binary subdirectory for each platform contains up to 470 programs. The total amount of source code just in the main languages (Asymptote, C, C++, Java, Lisp, PostScript, and Web) and in five scripting languages (awk, lua, perl, python, and shell) is about 4_908_000 lines. In addition, in the final TeX Live installation tree, there are about 8_500_000 lines of code in the TeX macro language. In round figures, there are more than 13 million lines of code in TeX Live 2022!

Many of the source packages that are built and included with TeX Live distributions are handled independently by other developers outside the TeX world, and the job of the TeX Live team each year is to find out by actual build experience how many of the latest releases of those other packages have build issues, or platform dependence, or nasty CPU-architecture assumptions.

In view of those observations, it should be no surprise that the annual TeX Live production takes team members about three months of hard work, and that there are numerous platforms where builds are only partially successful, and thus, some programs are missing from the binary subdirectories, as illustrated by the large table near the beginning of this Web page.


Building TeX Live 2022 with clang compilers

Since TeX Live production began, outside the Microsoft Windows world, the default compiler family at most team builder sites has been gcc (GNU Compiler Collection). That family has been ported to almost all operating systems in common use, has front ends for multiple languages (Ada, Brig, C, C++, D, Fortran, Go, JIT, LTO, Objective C, and Objective C++), plus support for Java and Pascal on older gcc releases, and has backends for all major CPU architectures used in desktop and server computers.

gcc is released under the terms of the GNU General Public License, version 2 (June 1991). That license contains requirements that derivatives of the code must be similarly licensed, and made available in source form, to guarantee freedom of use for everyone.

Some find that license too restrictive, and several other open-source licenses have been proposed. Among them are the simpler BSD 2-clause and 3-clause licenses common in the BSD operating system family, and the Apache License version 2.0 (January 2004) that is used by many Web servers, and by the other major compiler family, LLVM + Clang.

Starting in 2012, FreeBSD developers began a move towards using the LLVM compilers as the default, and that operation was completed with the FreeBSD 10.0 release in January 2014. OpenBSD has made a similar change, but NetBSD still uses gcc. On all of those systems, multiple versions of both compiler families are available in the package system, sometimes right up to weekly snapshots of gcc that are only a few days old.

Because gcc has a much longer history than clang, in order to be competitive, the latter attempts to recognize common gcc language syntax additions (often added to satisfy the requirements of operating-system kernel authors), as well as some, but certainly not all, of the gcc command-line options.

As long as software authors are aware of both compilers, they can generally take steps to avoid tying their code to just a single compiler. Alas, at least one vendor, Apple in macOS, offers a program called gcc that is just a wrapper around clang, and that often fails to compile code that makes tests of gcc-specific preprocessor symbols. It must be emphasized that clang, while it has become an excellent compiler, is far from a superset of gcc's capabilities, and targets only a small number of CPU architectures compared to those that gcc supports.

One particular behavior difference between the two compiler families that is exposed by TeX Live builds is that gcc always automatically searches /usr/local/include for header files, and /usr/local/{lib,lib64} for library files, but clang does not! That difference can be harmless on Linux distributions, but in the DragonFlyBSD, FreeBSD, and OpenBSD worlds, /usr/local has been usurped for the vendor package systems, belying its name.

To address deficiencies of various operating systems, and deal with version-number dependencies of needed libraries, TeX Live itself contains library source code for things like data compression and Unicode support, and the build process may expect those private versions to be used. Depending on the settings of the -Wl,-rpath and -L compiler options that name directories where libraries are searched for, compilation may succeed with gcc, but fail with clang, when the latter finds the wrong libraries.

It is unclear whether a clean solution to this behavior mismatch exists, given that TeX Live 2022 contains about 2375 directories and about 270 Makefiles. I have been able to use both compiler families for building TeX Live 2022 on FreeBSD 13 x86_64, and to use clang (but not gcc) on OpenBSD 6.9 x86_64. However, because of compiler version-dependent C++ library requirements, it seems less useful to use clang on other platforms: end-user sites might then find some TeX Live executables unusable until they installed clang binary packages themselves. Our systems at Utah have numerous versions of both compiler families compiled from source code and installed, and a tree for just one recent version of clang takes about 2GB of disk space.

Many users of TeX Live installations are unlikely to know much about computer system management, and would not even know how to find and install binary packages for additional compilers, so the TeX Live team has to try to produce a software installation that works out of the box for the largest number of users. Thus, various versions of gcc remain the predominant choice for building TeX Live.


Build reports for various platforms

This major section contains reports of the TeX Live 2022 build experience on numerous platforms, in alphabetically ordered subsections: just scroll down to any that are of interest to you, or follow links from the contents listing.

For TeX Live 2022, a new engine, HiTeX, is included in the source tree, but not compiled by default. That default has been overridden at Utah with build recipes like this:

    env TL_CONFIGURE_FLAGS=--enable-hitex $prefix/src/texlive/build-texlive-2022.sh texlive-YYYYMMDD

With rare exceptions, just before a TeX Live build is attempted, operating system package updates are run, and the build host rebooted if necessary, so the build is done with the latest available software.

Here are links to the contents of this section:


Absolute 15 x86_64 success

Absolute Linux, dating from late 2008, is a member of the Slackware family, although it uses a somewhat different package manager, a different binary package repository, and has a smaller package selection. For example, it lacks emacs, gcc-gnat, PostgreSQL, tcsh, TeX Live, and zile. However, it does have clisp by default, and once the /usr/include/glm directory was installed from source code (see the Slackware report), the build of TeX Live and Asymptote was problem free.


AlmaLinux 8 x86_64 success

In early 2021, Red Hat announced that the formerly stable cost-free operating system, CentOS, would move in its next version, 8, to a rolling-release model. That decision disappointed many CentOS 7 sites, and led to the creation of new distributions, AlmaLinux (released 31-Mar-2021), EuroLinux, Navy Linux, Rocky Linux (released 1-May-2021), and Virtuozzo Linux (VZLinux) that plan to continue the practice of multiyear stability of the GNU/Linux operating system.

In late 2021, support for CentOS 6 was ended, but CentOS 7 will get updates until mid-2024. A preliminary release of CentOS 9 appeared in December 2021.

I created a new virtual machine for AlmaLinux on the day of its first release, configured it with user accounts, installed numerous binary software packages, installed Clisp from source code, and then a build of the TeX Live 2021 final source snapshot of 25-Mar-2021 was completely successful. A rebuild for TeX Live 2022 was similarly successful.


Alpine 3.13 and 3.15 x86_64 success

Alpine Linux 3.13 was released on 14-Jan-2021, and 3.15 appeared on 14-Nov-2021.

Alpine Linux is unusual among Linux distributions in that it is based on the MUSL C standard library, rather than the GNU one. Our site has test machines for several versions of Alpine Linux, but only one non-Alpine system that uses MUSL: Void Linux MUSL on x86_64.

The major impediment to building a full TeX Live 2022 system on Alpine Linux is that its binary package system lacks clisp and the -lsigsegv library. Most Alpine versions also lack the -lffcall library, although it is available in Alpine 3.12 and later. Fortunately, I had previously built clisp on Alpine 3.6.2, and I found that, after building and installing the two dependent libraries on Alpine 3.11, I could then build Clisp. However, its installed lisp.run file still had dependencies on shared libraries that I wanted replaced with statically linked libraries. By removing the *.run files from the clisp build tree, editing the Makefiles to replace references to -lxxx libraries with pathnames for the static libraries, and restarting make, I was able to rebuild clisp so that its lisp.run file has only these dependencies:

        $ ldd $prefix/lib/clisp-2.49.92/base/lisp.run
        /lib/ld-musl-x86_64.so.1 (0x7f72c5958000)
        libreadline.so.8 => /usr/lib/libreadline.so.8 (0x7f72c55a8000)
        libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7f72c554d000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f72c5958000)

Despite my replacing references to -lreadline with the static library, there is still a reference to its dynamic library. Fortunately, the listed libraries are also available on Void Linux MUSL.

With clisp installed locally, and extra installations of ghostscript and texinfo, the build of all of TeX Live, and Asymptote, succeeded on Alpine 3.11.6 in 2020, on Alpine 3.12.3 in 2021, and on Alpine 3.13.5 in 2022. On the latter, the default compiler family is gcc-10.2.1.

Further tests in 2021 showed that the Alpine 3.11.6 binaries work on Void Linux, and on Alpine Linux back to 3.6.5 (3.6.0 released May 2017). However, on some of those older versions, there are missing libraries that I resolved by creating symbolic links to existing libraries, and setting the environment variable LD_LIBRARY_PATH. Alternatively, one can simply copy the missing library version from a compatible O/S. If there is a need for a build on an older Alpine version, please contact the author of this site.

Once libffcall, libsigsegv, and Clisp were built from source code and installed, the builds of TeX Live 2021 and 2022 were successful.


ArchLabs x86_64

ArchLabs on x86_64 is a distribution based on ArchLinux. A build of TeX Live 2022 with the gcc-11.1.0 compiler family was successful.


Arch Linux ARM7L (32-bit)

We have several small Wandboard Quad boxes used for dedicated network services and software development and testing. In 2014, each cost less than USD200. They contain a Cortex-A9 4-core 1GHz ARM rev 10 (v7l) processor, 2GB of DRAM, and a 32GB MicroSD card with an EXT4 filesystem. One of them, used for this build, has an external 128GB disk. They run Arch Linux (a rolling release O/S) in little-endian addressing mode.

In 2022, the Linux kernel version is 5.11.2-1-ARCH, and the C/C++ compilers available on this system are from gcc-9.2.0. The Arch Linux package system for this machine contains TeX Live 2021. The build of TeX Live 2022 completed without problems.

Warning: There are numerous models of ARM processors, manufactured by several different companies, sometimes with differing subsets of the ARM instruction set architecture. Most can run with either big-endian or little-endian addressing, but which of those is in effect is determined by the operating system chosen for installation. Thus, even if you have an ARM system running some Linux distribution, you might not be able to use our TeX Live 2022 binaries.


Arch Linux x86_64

A build of TeX Live 2022 on Arch Linux x86_64 with the native gcc-11.1.0 compiler family was successful.


Artix Linux x86_64

Artix Linux is a rolling release distribution that uses the pacman package manager from Arch Linux. A build of TeX Live 2022 with the native gcc-11.1.0 compiler family was successful.


CentOS 5.11 x86_64 partial success

CentOS 5 was introduced in April 2007, and vendor support ended in March 2017. We retain only a single system running this operating system, and then only for testing purposes. Its default compiler family is gcc-4.1.2 (2008), which is too old to compile parts of recent TeX Live releases. Nevertheless, because I have built and installed many later versions of gcc, by using gcc-8.3.0 (2018), I was able to get about 90% of the executables to build. That is not adequate, but it illustrates where the problem areas lie on older GNU/Linux systems.

No attempt was made to build TeX Live 2022 on this system.


CentOS 6.10 x86_64 partial success

Vendor support for CentOS 6, first introduced in July 2011, ended in November 2020. Nevertheless, my site has a significant hardware investment in Sun Ray thin clients that require this operating system, and funds have not yet been found to replace them with newer workstations. In recent years, TeX Live builds on CentOS 6 have had many problems, and it has not been possible to build all of the expected executables. The year 2021, surprisingly, saw some improvements: only Asymptote is not buildable.

Our last CentOS 6 systems were retired in late 2021, and no attempt was made to build TeX Live 2022 on this operating system.


CentOS 7.9 PPC64BE failure, then success

The IBM POWER, and later, PowerPC, CPUs were the first commercially successful RISC microprocessors (POWER stands for Performance Optimization With Enhanced RISC). POWER appeared on the market in the IBM RS/6000 workstation in February 1990, and was the CPU design that introduced the Fused Multiply-Add (FMA) instruction that is so useful that it is now a requirement of the 2008 and 2019 IEEE 754 Standards for floating-point arithmetic, and is a key component in much modern research in computer arithmetic.

The IBM System/360 family (later named System/370, System/380, System/390, and now, zSeries or z/Architecture) introduced in April 1964 was the first to use byte addressing, and had the reasonable convention that memory is viewed as a linear stream advancing from 0 on the left to the highest address on the right, and thus, the address of any multibyte object is always that of its first byte from the left, which is then the high-order byte of any numeric value.

POWER and PowerPC support that big-endian addressing convention, but because the DEC PDP-11, DEC VAX, and Intel x86 and x86_64 architectures address objects by their rightmost (and low-order) byte, a practice known as little-endian addressing, the IBM CPU designs also support that alternate convention, although a given system must be entirely in traditional big-endian order, or in little-endian order. Since then, ARM, MIPS, RISC-V, and SPARC CPU designs also support big-endian and little-endian addressing, although in their markets, only one or the other of those has been used in practice.

IBM's own AIX operating system on POWER and PowerPC is big-endian, but CentOS and Red Hat Linux distributions are available for both endian designs. My test lab includes VMs for both, because programmers have too often made false assumptions about byte order in multibyte objects, compromising software portability. TeX Live builds in previous years have on occasion found endian bugs in support software.

The main TeX Live 2021 build on CentOS 7.9 on PowerPC64 in big-endian addressing mode was problem free. The Lua JIT programs are missing, because they are not supported on that architecture. Asymptote failed to build in January 2021, but a build with the texlive-20210317 snapshot was successful, once I removed the C++ compiler option -static-libstdc++: that library is not available.

A build attempt failed for TeX Live 2022 on this system, because some of it components require ISO C++ 2014 support, and the native compilers (gcc-4.8.5) are too old for that language level. I enabled the Extra Packages for Enterprise Linux (EPEL) repository, which on some systems offers newer compiler builds. Alas, for the PowerPC architecture, EPEL has no compilers newer than the gcc-4.9.3 family.

Web searching found no further package repositories for this system, so I decided to try to build new compilers myself. The gcc compiler family is an enormously complex system to build, and build failures have been frequent. Also, the PowerPC CPU in my VM is emulated in software, rather than running on native hardware, so the performance of the VM is about 15 to 30 times slower. I chose the oldest version, gcc-8.5.0, known to work TeX Live 2022 on other platforms, selected a build of compilers for only C, C++, and Fortran, and began the job. Five days and six hours later, to my surprise, it completed successfully, so I installed it. With those new compilers, a TeX Live 2022 build, including Asymptote, was successful.


CentOS 7.9 x86 success

This is the last release of CentOS for 32-bit x86, and support for CentOS 7 ends on 30 June 2024. Later releases of CentOS, Fedora, and Red Hat Enterprise Linux drop support for this architecture, and concentrate on x86_64, with some support for other CPU designs. The last manufactured Intel x86 CPU may be the Pentium Dual-Core in 2007.

A build of TeX Live 2022, including Asymptote, using the locally installed gcc-6.5.0 compiler family, was successful. The native /usr/bin/gcc compiler is version 4.8.5 (20150623), too old to build TeX Live.


CentOS 7.9 x86_64 success

The native compilers on this system are from the gcc-4.8.5 family, too old to support the ISO C++ 2014 Standard. No later compiler versions are available in the CentOS package system. A TeX Live 2022 build is thus impossible on this systems with those compilers.

Fortunately, I have long built and installed gcc versions enhanced with support for decimal floating-point arithmetic, and our CentOS systems have numerous versions of that compiler family from 4.x to 12.x. The build of the main part of TeX Live 2022 was successful with this recipe:

    env CC=$prefix/bin/gcc-8.5.0                                                                        \
        CXX=$prefix/bin/g++-8.5.0                                                                       \
        LDFLAGS="-L$prefix/ashare/gcc/gcc-8.5.0/lib64 -Wl,-rpath,$prefix/ashare/gcc/gcc-8.5.0/lib64"    \
        $prefix/src/texlive/build-texlive-2022.sh texlive-20220121

A similar command with the script build-asymptote.sh built Asymptote.


CentOS 8.4 PPC64LE success

The TeX Live 2022 build on a PowerPC64 little-endian CentOS 8.4 operating system succeeded. The native compilers are from the gcc-8.4.1 family.


CentOS Stream 8 x86_64 success

The TeX Live 2022 build with native compilers (gcc-8.5.0) on the now rolling release CentOS 8 Stream was flawless, and the extra option needed on CentOS 7 is not required.

The RedHat and CentOS package systems have never supplied Clisp, so I built and installed libffcall, libsigsegv, and clisp from source code.


CentOS Stream 9 x86_64 success

The TeX Live 2022 build with native compilers (gcc-11.2.1) on CentOS 8 Stream was successful.

The RedHat and CentOS package systems have never supplied Clisp, so I built and installed libffcall, libsigsegv, and clisp from source code.


Debian 10.6 PPC64LE success

The TeX Live 2022 build with native compilers (gcc-8.3.0) on Debian 10.6 (code name buster) on little-endian PowerPC64 completed successfully, except for the Lua JIT programs, which are not supported on that architecture.


Debian 11 Alpha success

The DEC Alpha architecture was introduced in 1992 as a fresh 64-bit RISC design intended to replace the 32-bit DEC VAX architecture. Initially, Ultrix and OSF/1 (DEC's flavors of Unix, with OSF/1 later rebranded as Tru64), and VMS operating systems were available. Later, other Linux distributions, and Microsoft Windows, were ported to Alpha systems. Some header files in the /usr/include tree in Sun Solaris have conditional sections for the Alpha architecture, so Solaris may too have run on the Alpha, although it was likely never released to Sun customers.

C language implementations on Alpha use 32-bit integers for the type int, but 64-bit integers for the types long int and long long int. The Alpha may have been the first CPU family for which long int is a 64-bit type; I recall dealing with portability issues on our several Alpha systems with software that assumed a 32-bit size for that type. The ISO C99 Standard later introduced types with embedded bit sizes, such as int32_t and uint64_t, to help with such problems.

In 1998, DEC, once the world's second largest computer company, with IBM in first place, was sold to Compaq, and in 2002, that was absorbed by Hewlett-Packard. The joint Intel/HP effort to design a 64-bit replacement for the x86 architecture led to the development of the IA-64 architecture, code named Itanium. The last Alpha CPUs were produced in 2004.

The Alpha design has both VAX and IEEE 754 floating-point instructions. Early Alpha models hard-coded the IEEE 754 rounding direction into the instruction mnemonics, but later models offered dynamic rounding control, as required by IEEE 754. Near the end of its production life, Alpha CPUs with 128-bit IEEE 754 arithmetic in hardware became available, but our older Alpha physical systems only had that format in software emulation.

In past years, I have made several attempts to create usable Alpha systems with Linux and FreeBSD using QEMU emulation, but failed. However, on 12-Jun-2021, I successfully created a stable Debian 11 system on Alpha, and have installed several of my own software packages on that system.

The C and C++ preprocessors on Debian Alpha define the symbols __alpha, __alpha__, and __alpha_ev4__. The latter represents a particular CPU model. The Debian 11 lscpu command actually reports the model as EV67, and the pseudofile /proc/cpuinfo reports it as a Tsunami Clipper variant. Like the earlier PDP-11 and VAX systems, Alpha memory addressing is little-endian.

Although Clisp is in the Debian binary package archive for this platform, it cannot be installed because of library version conflicts. However, after installing other library dependencies from binary packages, I was able to build and install Clisp from source code, using the recipe documented in the section on DragonFlyBSD.

The TeX Live 2021 and 2022 builds, including Asymptote, with native compilers (gcc-10.2.1) on Debian 11 (code name bullseye) on Alpha were then successful. The Lua JIT programs are not supported on that architecture.


Debian 11 ARM64 success

The TeX Live 2022 build with native compilers (gcc-10.2.1) on Debian 11 (code name bullseye/sid) on ARM64 (also known as aarch64) was problem free, once I added the option --disable-arm-neon to TL_CONFIGURE_FLAGS, as noted in the section on the FreeBSD 13.0 ARM64 build.

The build of Asymptote still has some missing library support, because I have yet to figure out exactly what extra Debian packages are needed to satisfy the feature tests:

    % asy --version
    Asymptote version 2.78 [(C) 2004 Andy Hammerlindl, John C. Bowman, Tom Prince]

    ENABLED OPTIONS:
    SSBO     GLSL shader storage buffer objects
    GSL      GNU Scientific Library (special functions)
    FFTW3    Fast Fourier transforms
    XDR      External Data Representation (portable binary file format for V3D)
    CURL     URL support
    Readline Interactive history and editing
    Sigsegv  Distinguish stack overflows from segmentation faults
    GC       Boehm garbage collector
    threads  Render OpenGL in separate thread

    DISABLED OPTIONS:
    V3D      3D vector graphics output
    WebGL    3D HTML rendering
    OpenGL   3D OpenGL rendering
    LSP      Language Server Protocol

Debian 11 M68K partial success

The 32-bit Motorola 68000-family complex instruction set (CISC) processors of the 1980s and 1990s were used in early workstations from Amiga, Apple, AT&T, HP, NCR, NeXT, Sinclair, Sun, and others. The last CPU model in the series was the 68060 in 1994, after which Motorola moved its production to the higher-performing IBM PowerPC RISC CPUs.

Floating-point instructions for the early M68K CPUs were handled by separate chips, the Motorola 68881 and 68882 co-processors. The Motorola 68040 finally included floating-point on the main CPU. Their design follows the IEEE 754 binary floating-point standard, with 32-bit, 64-bit, and 80-bit formats, and includes instructions for computing most of the elementary functions, albeit in limited argument ranges for some of them.

Addressing on all M68K systems is big-endian. The C and C++ preprocessors define several symbols that identify the architecture, including __m68k__, __mc68000__, and __mc68020__.

The M68K CPUs are still supported in a few operating-system distributions, including Debian, and in June 2021, after earlier failed attempts, I managed to create a stable working virtual machine for Debian 11 with QEMU emulation of the Motorola 68040.

Clisp and other tools and libraries needed for TeX Live are available in the binary package archive.

The TeX Live 2021 build with native compilers (gcc-10.2.1) on Debian 11 (code name bullseye) on M68K succeeded, apart from the platform-limited Lua JIT programs. Asymptote builds, but when run, it dies with an error such as Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.

For TeX Live 2022, all but Asymptote and Lua JIT built successfully.


Debian 11 s390x success

The TeX Live 2022 build with native compilers (gcc-10.2.1) on Debian 11.1 (code name bullseye) on s390x was successful.


Debian 11 SPARC64 success

The TeX Live 2022 build with native compilers (gcc-11.2.0) on Debian 11 (code name bullseye) on SPARC64 was successful.

The build host is a physical one: a 2007-vintage Sun SPARC Enterprise T5240 (2 16-core 64-thread CPUs, 1200 MHz UltraSPARC T2 Plus (Niagara2), 64GB DRAM), and CPU variant sun4v. On both Solaris SPARC and Debian SPARC64, addressing is big-endian.


Debian 12 x86_64 success

The build of TeX Live 2022 using the native gcc-11.2.0 compiler family on Debian 12 x86 was successful.


Devuan Linux 3.1 and 4.0 x86_64 success

Devuan Linux is a derivative of Debian Linux, with complete removal of the complex systemd startup management system. The build of all of TeX Live 2022 was successful on a Devuan 3.1 (beowulf) system with the gcc-8.3.0 compiler family, and also on a Devuan 4.0 (chimaera) VM with the gcc-10.2.1 compiler family.


DragonFlyBSD 5.9, 6.0, and 6.2.1 x86_64 success

DragonFlyBSD was forked from FreeBSD 4.x in 2003 with the intent of significantly improving multiprocessor and multithreaded performance, and of developing a completely new filesystem, Hammer, capable of distributed storage replication and file-based snapshots. By 2019, the kernel had been demonstrated to be capable of running over a million simultaneous processes, and network throughput has been significantly improved over DragonFlyBSD releases just a few years older.

As of 2022, DragonFlyBSD still runs only on x86_64 (amd64) hardware. One may hope that, with the rise of ARM64 and RISC-V64 in the market, it may be ported to those CPU families in the future.

In late August 2019, a DragonFlyBSD developer announced an early implementation of dfbeadm, similar to the beadm (Boot Environment ADMinistration) command in the Solaris and some BSD families, to make it easy to capture the state of the entire system before a major upgrade and a reboot. If problems arise from the upgrade, one can use dfbeadm to revert to the previous boot environment, and reboot, restoring the system to its pre-upgrade state.

Our test laboratory has included virtual machines for DragonFlyBSD versions from release 3.2 in late 2012, up to the latest, 6.2.1, in January 2022.

Because of significant kernel and library differences, DragonFlyBSD is not capable of running FreeBSD executables, but its development team has an outstanding record of supplying a large prebuilt binary package repertoire (more than 30_000 packages at release 6.2.1), including the latest development versions of gcc 4.x to 12.x, as well as clang versions from 6.x to 13.x. I have found DragonFlyBSD a pleasant and reliable system to use. Generally, if software packages can be built on GNU/Linux and FreeBSD, they should also be buildable on DragonFlyBSD.

The DragonFlyBSD development cycle is fairly short, and binary package archives for older releases tend to disappear from the Internet, so users need to be prepared to run O/S updates at least a couple of times a year.

Until recently, the DragonFlyBSD package system did not supply clisp, but after installing some needed libraries, I built it without problems from source code with these commands:

    % tar xf /some/path/to/clisp-2.49.92.p3.tar.gz
    % cd clisp-2.49.92.p3
    % ./configure --prefix=$prefix                          \
                --with-libffcall-prefix=/usr/local          \
                --with-libiconv-prefix=/usr/local           \
                --with-libpth-prefix=/usr/local             \
                --with-libreadline-prefix=/usr/local        \
                --with-libsigsegv-prefix=/usr/local         \
                --with-libunistring-prefix=/usr/local       \
        && gmake all check
    % gmake install

After Clisp was added to the package system, all that is needed is

    # pkg install clisp

The bin subdirectory of this Web site contains a complete set of TeX Live 2022 binaries, but only for the three most recent versions of DragonFlyBSD.


EuroLinux 8 x86 success

EuroLinux is one of several distributions that offer a stable versioned equivalent of CentOS 8.x, as an alternative to the rolling release model of CentOS Stream 8.

Using my locally built Clisp installation, and the native gcc-8.5.0 compiler family, a build of TeX Live 2022 was successful on EuroLinux release 8.5 (Tirana).


Fedora 34 x86_64 success

A build of TeX Live 2022 on Fedora 34 (Workstation Edition) with the native gcc-11.2.1 compiler family was flawless.


Fedora 36 x86_64 success

A build of TeX Live 2022 on Fedora 36 (Rawhide Prerelease) with the native gcc-11.2.1 compiler family was flawless.


FreeBSD 10.4 amd64 success

FreeBSD 10.0 became available in January 2014, and the final 10.4 in October 2017. The native TeX installation at that level is from TeX Live 2015.

Support for the FreeBSD 10.x family was terminated in October 2018, and its binary package repository is no longer accessible. Fortunately, there is a high degree of upward compatibility of software in FreeBSD, so upgrades rarely break existing user-built software, and it is generally easy to install newer O/S releases.

The TeX Live 2022 build with the native GNU compilers (gcc-7.3.0) on FreeBSD 10.4 AMD64 (= x86_64) was problem free. For Asymptote, I had to use the newer gcc-8.2.1 compiler family, and I also had to add /usr/local/lib/gcc8/libstdc++.a to the GCLIB variable in the Makefile to avoid references to an obsolete library.


FreeBSD 11.4 amd64 success

The TeX Live 2022 build with the native GNU compilers (gcc-8.4.1) on FreeBSD 11.4 AMD64 (= x86_64) was problem free.


FreeBSD 12.3 amd64 success

The TeX Live 2022 build with the native GNU compilers (gcc-10.3.0) on FreeBSD 12.3 AMD64 (= x86_64) was problem free.


FreeBSD 13.0 amd64 success

The FreeBSD binary package repository is also the source of packages for several related BSD variants. Regrettably, even the latest FreeBSD development version only supplies TeX Live 2015. The annual builds available at this site, and in the TeX Live DVDs, for that system can help to remedy that serious deficiency.

The TeX Live 2022 build with the native GNU compilers (gcc-10.3.0) on FreeBSD 13 AMD64 (= x86_64) was problem free.


FreeBSD 13.0 ARM64 partial success

The TeX Live 2022 build with the native GNU compilers (gcc-10.3.0) on FreeBSD 13 ARM64 initially failed because a configure script reported that it could not find libpng. That library, and its header files, was already installed on the system, so I restarted the build with explicit compiler and linker flags pointing into the /usr/local tree where FreeBSD installs packages.

That failed again, for the same reason, so I pulled down a fresh TeX Live source snapshot, dug further into the configure failure, and found that it was really due to a completely different cause: test code that used ARM NEON intrinsics. A search of the binary package repertoire found two candidates: gstreamer1-plugins-neon and neon. I installed both, and retried a fresh build. It failed exactly as before.

I then searched top-level configuration options, added --disable-arm-neon to TL_CONFIGURE_FLAGS, and did a new build. That finally succeeded. That extra option has now been added to the build-texlive-2022.sh script, so it need not be supplied explicitly.

A build of Asymptote failed because of assumptions for FreeBSD about the floating-point environment that turn out to hold only for AMD64 (x86_64), but not for other CPU architectures. I'm working with the author of Asymptote to find a workaround.


FreeBSD 14.0 amd64 success

A prerelease of FreeBSD 14.0 became available on 11 March 2021. A build of TeX Live 2022 with the gcc-10.3.0 compiler family was successful. The version history of FreeBSD suggests a new major release about every two years, so version 14.0 may be official some time in 2023.


GhostBSD 21.11 and and 22.01 amd64 success

GhostBSD is derived from FreeBSD, and for software builds, the two systems are quite similar. Using the gcc-9.4.1 compiler fmaily, TeX Live 2022 built without problems on GhostBSD 21.11 and 22.01 amd64. which are based on FreeBSD 13.0, the latest stable release of that O/S.


HardenedBSD 13.0 and 14.0 amd64 success

HardenedBSD is a derivative of FreeBSD with a goal of implementing additional security features to make hostile attacks more difficult. For a comparison of such features in major members of the BSD family, visit this site.

Our test environment has HardenedBSD instances for major versions 11, 12, 13, and 14, corresponding to those versions in FreeBSD. The binary software package systems for HardenedBSD contain from 28_500 to 29_900 packages. Clisp is not included in those systems, but fortunately, Clisp version 2.49.92 builds without issues on HardenedBSD, and I have done so on each of those machines.

On the corresponding FreeBSD releases, Clisp is available in the package systems, and they offer about 2_000 more packages than on HardenedBSD.

The default C/C++ compiler family on the versions of HardenedBSD is clang version 5 in 11 and 12.0, version 10 in 12.2, version 11 in 13.0, and version 13 in 14.0. Versions of the gcc family are available as optional packages; their defaults are 6.4.0 in 11.0 and 12.0, 9.4.0 in 13.0, and 11.2.1 in 14.0. All of those gcc versions are capable of building TeX Live 2022, and the builds, including Asymptote, succeeded without problems.


Mint 20.3 x86_64 success

Linux Mint is a popular Debian-based desktop system. The latest version, Mint 20.3 (Una), appeared on 4 January 2022, so I created a new VM for it, and successfully built and installed TeX Live 2022.

The native compiler families are gcc-9.3.0 and clang-10.0.0 (both from 2020), about 2 or 3 major versions behind compilers in other recent operating system distributions. However, the package system also supplies optional, and more recent, gcc-10.3.0, clang-10.0.0, clang-11.0.0, and clang-12.0.0 compiler families.


Navy Linux Enterprise 8.4 x86_64 success

Navy Linux Enterprise 8.4 is one of several distributions that offer a stable versioned equivalent of CentOS 8.x, as an alternative to the rolling release model of CentOS Stream 8.

Using the native gcc-8.4.1 compiler family, builds of libffcall, libsigsegv, clisp, and TeX Live 2022 were successful on Navy Linux Enterprise release 8.4-2 (Base).

More recent GNU compilers are available in the gcc-toolset-9 and gcc-toolset-10 packages, which install in subdirectories of /opt/rh, instead of the usual /usr tree. They currently provide gcc versions 9.2.1 and 10.2.1. The clang-11.0.0 compiler family is also available in the package system.


NetBSD 10 amd64 partial success

Our NetBSD 10 system is a development version of NetBSD that is not yet on a release schedule, but based on past history, might become official in 2022. Its /etc/release file, and the output of uname -r, both report a version of 9.99.52.

The build of TeX Live 2022 with the native gcc-8.4.0 compiler release was successful.


OpenBSD 7.0 amd64 partial success

Unlike most other O/S distributions, OpenBSD makes no guarantee of upward compatibility of compiled binary executable programs in major and minor releases. Thus, locally installed software that requires compilation must be rebuilt at each OpenBSD release. Our test site has OpenBSD versions from 4.0 (November 2006) to the latest 7.0 (August 2021), but the master site provides downloads only for the latest O/S version, and packages only for the last five minor versions. Unlike many other O/S distributions, between-release package updates are not common on OpenBSD, so the system remains relatively stable for months at a time.

Before OpenBSD 7.0, an old gcc-4.2.1 release from 2007 was in the package system, but it has now been dropped from OpenBSD. There is a /usr/local/bin/egcc executable that corresponds to gcc-11.2.0, but no corresponding eg++ compiler. A build of TeX Live 2022 with the native LLVM Clang compilers (version 11.1.0) produced a successful build of all but Asymptote.

The Asymptote compilation problems can likely be repaired, and have been reported to the code's author.


OpenIndiana Hipster i86pc success, after HiTeX patches

On 24-Apr-2021, I built a new virtual machine from the latest available ISO image of 5-Apr-2021 for OpenIndiana Hipster, a member of the OpenSolaris 11 family, running on QEMU on Ubuntu 20.04. The native C/C++ compiler versions are gcc-7.5.0. I also installed the OpenCSW (Community Software) distribution that provides a Clisp binary, and built a second Clisp from source code.

For TeX Live 2022, using the gcc-10.3.0 compiler family, the build failed because the HiTeX code defines a private data type, label_t, that conflicts with a type name in system header files. The quick solution was to patch the HiTeX code like this:

    % cd /path/to/build/directory/texlive-20220105/source/texk/web2c/hitexdir
    % gsed -i -e s/label_t/hitex_label_t/g hitex.w hiformat.w hiparser.c hiparser.y

The default 32-bit build, including Asymptote, was then completely successful.

On 28 January 2022, I built a new Hipster VM from the latest available ISO image, and after package installations, got another successful build of TeX Live from a source snapshost taken six days earlier, without needing HiTeX patches. However, I had to add the directory /usr/perl5/5.34/bin to the front of the PATH directory list to get the needed, but otherwise missing, pod2man tool.

Because this is a new VM, I decided to document here the extra packages that I installed to allow a TeX Live build, and an Asymptote build:

    # pkg refresh

    # pkg update --accept

    # pkg install                               \
            archiver/gnu-tar                    \
            build-essential                     \
            developer/build/gnu-make            \
            file                                \
            file/gnu-coreutils                  \
            file/gnu-findutils                  \
            gcc-10                              \
            library/gmp                         \
            library/mpfr                        \
            pkg:/developer/as                   \
            pkg:/developer/gnu-binutils         \
            system/header                       \
            system/prerequisite/gnu             \
            text/gnu-diffutils                  \
            text/gnu-grep                       \
            text/gnu-patch                      \
            text/gnu-sed

    : More packages for Asymptote and local bibliography tools:

    # pkg install                                       \
            clisp                                       \
            freeglut                                    \
            freetype-2                                  \
            ftgl                                        \
            gsl                                         \
            libglew                                     \
            libxft                                      \
            mariadb-103                                 \
            pkg:/runtime/perl-524@5.24.3-2020.0.1.3     \
            pkg://openindiana.org/database/postgres-12  \
            pkg://openindiana.org/database/sqlite-3     \
            pkg://openindiana.org/library/math/glm      \
            yaz

The Asymptote executable has all of the optional packages that we try to supply for other operating systems:

    % asy --version
    Asymptote version 2.77 [(C) 2004 Andy Hammerlindl, John C. Bowman, Tom Prince]

    ENABLED OPTIONS:
    V3D      3D vector graphics output
    WebGL    3D HTML rendering
    OpenGL   3D OpenGL rendering
    SSBO     GLSL shader storage buffer objects
    GSL      GNU Scientific Library (special functions)
    FFTW3    Fast Fourier transforms
    XDR      External Data Representation (portable binary file format for V3D)
    CURL     URL support
    Readline Interactive history and editing
    Sigsegv  Distinguish stack overflows from segmentation faults
    GC       Boehm garbage collector
    threads  Render OpenGL in separate thread

    DISABLED OPTIONS:

openSUSE Jump x86_64 success

In mid-2020, the openSUSE project released a new distribution called Jump. Like the Tumbleweed distribution, Jump is also a rolling release.

The TeX Live 2022 build with the native gcc-7.5.0 compilers was flawless.


openSUSE Leap 15.4 Alpha x86_64 success

The TeX Live 2022 build on openSUSE Leap 15.4 Alpha x86_64 with the native gcc-7.5.0 compilers was successful.


openSUSE Tumbleweed x86_64 success

The TeX Live 2022 build on openSUSE Tumbleweed x86_64 with the native gcc-10.2.1 compilers was flawless.


Oracle 7.9 x86_64 success

Oracle 7 Linux is based on Red Hat Enterprise Linux (RHEL) 7, and the main build with the locally installed gcc-7.4.0 compiler family succeeded. However, Asymptote did not build because its configure script fails to find the math library; removing the -static-libstdc++ C++ compiler option resolved that problem. Red Hat family systems are deficient in failing to provide that library.


Oracle 8 x86_64 success

The main TeX Live 2022 build on Oracle 8 Linux with the native gcc-8.3.1 compiler family succeeded, and Asymptote could be built when the -static-libstdc++ option was removed.


Redcore x86_64 success

Redcore Linux Hardened 2102 (Polaris) is a recent rolling-release distribution inspired by Gentoo Linux: while some packages are available in precompiled binary form, many others require building from source code at end-user sites. Package updates therefore take much longer than on most other systems. The package system, sisyphus, is unique to Redcore.

Clisp and TeX Live are absent from the Redcore package system, so I built and installed libffcall, libsigsegv, and clisp from source code, using the gcc-10.3.0 compiler family. The TeX Live 2022 build then completed normally.


Rocky 8.5 x86_64 success

Using the native gcc-8.5.0 compiler family, builds of libffcall, libsigsegv, clisp, and TeX Live 2022 were successful on Rocky Linux release 8.5 (Green Obsidian).


Slackel 15 x86_64 success

Slackel 15.0 on x86_64 is a Slackware-based Linux distribution from Greece. In the author's experience with several major versions of Slackel and Slackware, Slackel has proved much more reliable. On numerous occasions, Slackware updates have trashed the VM filesystem, and required restoration of full disk images from backups.

Clisp is available in the Slackel package system, and I had already installed it on the VM. The build and installation of TeX Live 2022 was successful.


Slackware 15 x86_64 success

Slackware Linux is one of the earliest GNU/Linux distributions, first created in 1993. The current stable version was 14.2 at the start of 2022, but the long-awaited 15.0 was released on 3-Feb-2022.

I built a new VM for Slackware 15 using the full-install option. The Linux kernel version is 5.15.19, gcc is version 11.2.0, and clang is version 13.0.0, and recent compilers for Ada, C, C++, D, Fortran, Go, and Rust are already present from the initial installation. TeX Live 2021 is also installed, but Asymptote is absent from the Slackware package system.

After getting the system configured, without installing an additional packages, the build of TeX Live 2022, including Asymptote, was successful.

The one limitation is that 3D support in Asymptote is absent:

    % asy --version
    Asymptote version 2.77 [(C) 2004 Andy Hammerlindl, John C. Bowman, Tom Prince]

    ENABLED OPTIONS:
    SSBO     GLSL shader storage buffer objects
    GSL      GNU Scientific Library (special functions)
    FFTW3    Fast Fourier transforms
    XDR      External Data Representation (portable binary file format for V3D)
    CURL     URL support
    Readline Interactive history and editing
    Sigsegv  Distinguish stack overflows from segmentation faults
    GC       Boehm garbage collector
    threads  Render OpenGL in separate thread

    DISABLED OPTIONS:
    V3D      3D vector graphics output
    WebGL    3D HTML rendering
    OpenGL   3D OpenGL rendering

I installed several more packages in the hope of removing that limitation:

    # slackpkg reinstall egl-wayland gegl glade gnu libglade libglvnd mesa texinfo

Alas, after a clean rebuild of Asymptote, the feature list reported remained unchanged.

The key missing component is the C++ header file glm.hpp, but the slackpkg file-search "*glm*" command could not find it. Nor could package searches on older Slackware, SlackEL, and SlackEX systems. Further consulations with the Asymptote developer led to downloading a source package from http://downloads.sourceforge.net/ogl-math/glm-0.9.6.3.zip, then extracting and moving the glm header file subdirectory to /usr/include. This time, a rebuild of Asymptote produced an executable with no disabled options.

I have reported this easy workaround to the Slackware developers, because adding the glm package to their repositories should be a relatively simple task, and would also allow Asymptote to be a separately bundled package in Slackware distributions.


Solaris 11.4 i86pc success, after workarounds

Oracle Solaris 11.4 (build ID 11.4.28.0.1.82.3 of 15 December 2020) on i86pc (the designation for combined i386 and amd64) now has modern compilers, with gcc-10.2.0 and clang-10.0.0 families, and the main TeX Live 2022 build was flawless, except for those that need Clisp. Further investigation found a flaw in the OpenCSW packaging system: the executable /opt/csw/lib/clisp-2.47/base/lisp.run has references to missing libraries:

    # ldd /opt/csw/lib/clisp-2.47/base/lisp.run
    ...
      libavcall.so.0 =>        (file not found)
      libcallback.so.0 =>      (file not found)
    ...

I resolved that problem by creating two symbolic links:

    # cd /opt/csw/lib
    # ln -s libavcall.so.1.0.1 libavcall.so.0
    # ln -s libcallback.so.1.0.1 libcallback.so.0

A following fresh build successfully created the missing Clisp-based executables.

Asymptote failed to build, with the configure script falsely claiming that the math library (-lm) is missing.

Further investigation found the problem: my build-asymptote.sh script adds the flag -static-libstdc++ to the CXXFLAGS value, and the configure script fails if that library is missing, and produces an incorrect diagnostic about which library could not be found.

The reason for our use of that flag is that the shared C++ library is highly dependent on the compiler version, whereas using the static library companion removes that site dependency. Subsequent system updates can replace the C++ library with an incompatible one, breaking executables that were linked against the original library.

Unfortunately, even though g++ recognizes the compilation flag requesting use of a static C++ library, the Oracle packages for the supplied versions 7, 9, and 10 of the gcc compiler family fail to include the static library.

The workaround is to modify the build script to temporarily remove the static library flag, and when that was done, Asymptote built successfully. There are now no missing files in the Solaris 11.4 binary tree for TeX Live 2021, but it will be necessary for other sites that use that tree to ensure that the gcc-10 package has been installed so that the library /usr/lib/64/libstdc++.so.6 is present.

I plan to attempt builds from source of recent gcc compilers to get the missing static C++ library, and if they succeed, Asymptote will be rebuilt with new static libraries.

The bin/x86_64-pc-solaris2.11.tar.xz file for 64-bit Solaris was kindly contributed by Apostolos Syropoulos.


Springdale 8.5 x86_64 success

Springdale Linux is a long-running distribution from Princeton University that follows Red Hat, and like that O/S, lacks Clisp in the package system. Clisp is not even available from the three optional extra repositories, springdale-appstream, springdale-computational, and springdale-unsupported.

Our local VM for it runs Springdale Open Enterprise Linux 8.5 (Modena). Once libffcall, libsigsegv, and clisp were built and installed with the native gcc-8.5.0 compiler family, the TeX Live 2022 build was problem free.


Ubuntu 20.04 S390X partial success

This VM runs on the IBM mainframe architecture s390x, a recent member of the world's oldest upward-compatible architecture that began with IBM System/360 in April 1964. See earlier remarks about the two main IBM architecture families on which Unix systems can run. The current IBM mainframe systems are part of the IBM z/Architecture, where z means zero downtime, due to replication and automatic failover of critical components.

System/360 marked the first time that a commercial computer vendor offered a range of software-compatible machines. Until then, each vendor's new machine model was sufficiently different from its predecessor models that software largely had to be programmed anew. IBM's System/360 product-line idea changed the entire computing industry, and by the mid 1970s, most computer vendors offered a range of models that promised upward compatibility. CPU designs also became largely model independent, with the DEC VAX enjoying a two-decade run, and the Intel x86 and x86_64 a four-decade market.

System/360 was the first architecture with byte-addressable memory, and it initially supplied support for 8-, 16-, and 32-bit integer arithmetic, and 32- and 64-bit floating-point arithmetic with hexadecimal normalization. By 1972, 128-bit floating-point arithmetic was added and implemented in hardware in the larger models, and the Fortran compiler was extended with an Automatic Precision Increase option to move floating-point code to the next higher precision.

By the end of the 1990s, the architecture was extended with support for 64-bit integer arithmetic, and for IEEE 754 floating-point arithmetic in three sizes each for binary and decimal formats. Over its life, the address space has grown from 24 to 31 to 64 bits. Although it has always used big-endian addressing, support has been added for addressing of little-endian data.

Regrettably, the Debian, Fedora, and Ubuntu operating systems on s390x do not provide compiler access to the original hexadecimal floating-point types; they support only the IEEE 754 formats.

IBM was the first commercial computer vendor to introduce the idea of virtual machines: the earliest reference to their work that I can find is dated 1966. Although it took about three decades for the importance of virtualization technology to be understood by the rest of the computing industry, the author's build farm at Utah, and the whole industry of cloud computing, depend on virtualization. With adequate numbers of CPU cores, and substantial DRAM, my home and campus office workstations each run 70 to 85 VMs simultaneously, and repurposed older servers runs hundreds more.

During the TeX Live 2022 build work, I had to add a virtual disk to one VM that needed more space: it took a one-line command to shutdown the machine, another one-line command to create a new disk, a few mouse clicks and a file selection to add the disk to the VM, and two mouse clicks to restart the VM. It then took only a couple of minutes of work to format and mount the new disk, and add it to the system's /etc/fstab file that records filesystems to be mounted at boot time. On several VMs, where I had previously allocated only 1GB to 2GB of DRAM, I needed more memory for the TeX Live builds: it took a quick VM shutdown, typing the new memory size (4GB) into a box (4 characters), and a button click to restart the VM. By contrast, on two physical machines at home, I had to wait a week for new DRAM cards to arrive by express order from a factory in China, and then wait several more days for busy machines to be less busy, shut down the systems, disconnect and open their boxes, replace old cards with the news ones, reassemble and recable the boxes, and then power them on. Except for poor I/O performance, VMs are often an excellent solution for computing, giving access to additional platforms for software that is unavailable on your own system, for testing software portability, and for testing system updates in an easily recoverable VM before applying them to a physical machine that may be much harder to restore if the update causes problems.

C/C++ compilers on s390x define the symbols __s390__ (31-bit addressing) and __s390x__ (64-bit addressing) to allow compile-time detection of the architectures. Since 2015, the Linux kernel supports only the 64-bit model.

Available Linux distributions for s390x include Alpine, CentOS, Debian, Fedora, Gentoo, Red Hat Enterprise Linux, Slackware, SUSE, and Ubuntu.

There do not appear to be any BSD family operating systems for s390x, although I found one effort that appears to be dormant.

During extensive testing of numerical software on Ubuntu 20.04 on s390x, I found that I was able to crash the entire VM from unprivileged user code, often with ensuing file corruption, with my numerical tests. I eventually narrowed the problem down to a one-line C program that, when compiled and run, instantly caused the crash. The bug was in the emulation of the 128-bit IEEE 754 square root instruction, and was reported to the QEMU developers on 17 June 2020. Two days later, they found a fix that affected only a single line of code in QEMU's qemu-system-s390x emulator, but regrettably, it took almost six months for the fix to make it into the Ubuntu package system. Since then, the system has been stable, and no further surprises have turned up in my porting of large amounts of software to that machine.

The build of TeX Live 2022, including Asymptote, but excluding Lua JIT programs, and xindy, on Ubuntu 20.04 LTS on s390x with the native gcc-9.3.0 compilers was successful. The Lua JIT programs are missing, because they are not supported on that architecture. The xindy build failure happens because clisp suffers a segmentation fault.


Ubuntu 20.04 x86_64 success

The TeX Live 2022 build with native compilers (gcc-9.3.0) on Ubuntu 20.04 LTS (Long-Term Support, until April 2025) (code name Focal Fossa) on x86_64 was problem free.


Ubuntu 22.04 x86_64 success

The TeX Live 2022 build with native compilers (gcc-10.3.0) on an early development release of Ubuntu 22.04 (code name Jammy Jellyfish) on x86_64 was problem free.


Void Linux MUSL x86-64 success

The TeX Live 2022 build with native compilers (gcc-10.2.1) on Void Linux with the MUSL C library (instead of the usual GNU C library) had no issues, and Asymptote built as well.

The MUSL library was written beginning in 2011 to provide a clean, independent, and POSIX-conforming, redesign of the C run-time library. Besides Void Linux, other Linux distributions that use MUSL include Alpine, Dragora 3, Gentoo, and a few others: see Wikipedia for more about MUSL.


Virtuozzo Linux 8 x86_64 success

Virtuozzo Linux, or VZLinux for short, is one of several distributions that offer a stable versioned equivalent of CentOS 8.x, as an alternative to the rolling release model of CentOS Stream 8.

Once libffcall, libsigsegv, and clisp were built and installed with the native gcc-8.5.0 compiler family, the TeX Live 2022 build was problem free.


Zenwalk 15 x86_64 success

Zenwalk is a member of the Slackware Linux familyh, but has an additional set of package repositories that supplement those from Slackware, and uses a completely different package manager, netpkg, which has the annoying feature of prompting with a menu for each requested package to be installed. I could find no desktop GUI to run software updates, and when I first attempted to install a package, netpkg returned instantly with the unhelpful response Bye ;). After some experimentation, I found that netpkg -rr updates the record of package repository contents, and then subsequent installations worked.

A build of TeX Live 2022 on a new VM for Zenwalk 15 (which appeared a day after Slackware 15 was released) was successful. Unlike Slackware, clisp is not part of a full installation, so I had to install it with netpkg.

Like Slackware, there is no glm package, which is needed for 3D drawing support in Asymptote. The same trick used for Slackware of unbundling the glm-0.9.6.3.zip file, and then moving the glm header file directory to /usr/include, worked for Zenwalk.