Original version:
Wed Jan 6 08:39:18 2021
Last updates:
...
Wed Jul 14 19:28:25 2021
Current time in Salt Lake City, Utah, USA:
Saturday, 07-Dec-2024 10:23:45 MST
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, and 2020. |
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 2021 distribution. The official release is expected in April 2021, and should be available on DVD in mid-summer 2021; 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/texcol2021.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-2021.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 2021 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, and 2021 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 13 July 2021, the following builds have been (mostly) successful by the TeX Live team, or at Utah:
% show-file-counts.sh 460 aarch64-linux 454 alpha-debian11 462 amd64-freebsd 460 amd64-freebsd104 460 amd64-freebsd114 455 amd64-freebsd120 455 amd64-freebsd121 455 amd64-freebsd122 459 amd64-freebsd13-clang 461 amd64-freebsd13-gcc 460 amd64-freebsd130-clang 460 amd64-freebsd130-gcc 460 amd64-freebsd14-gcc 460 amd64-hardenedbsd111 460 amd64-hardenedbsd120 460 amd64-hardenedbsd122 460 amd64-hardenedbsd13 460 amd64-netbsd 460 amd64-netbsd100 460 amd64-netbsd72 460 amd64-netbsd82 460 amd64-netbsd91 456 amd64-openbsd64 455 amd64-openbsd65 455 amd64-openbsd66 418 amd64-openbsd67 456 amd64-openbsd68 455 amd64-openbsd69-clang 461 armhf-linux 460 armv7l-archlinux 462 i386-freebsd 460 i386-freebsd13 462 i386-linux 455 i386-linux-void 459 i386-netbsd 456 i386-solaris 460 i686-centos7 460 i686-fedora28 460 i686-opensusetw 460 i686-peppermint-10 425 i686-void32m 460 i86pc-openindiana 459 i86pc-solaris114 452 m68k-debian11 449 ppc64be-centos7 449 ppc64le-centos8 454 ppc64le-debian10 447 riscv64-freebsd14 452 riscv64-ubuntu2004 453 s390x-ubuntu2004 454 sparc-debian11 463 universal-darwin 460 x86_64-almalinux8 460 x86_64-alpine312 460 x86_64-alpine313 443 x86_64-centos5 459 x86_64-centos6 460 x86_64-centos7 460 x86_64-centos8 458 x86_64-darwinlegacy 460 x86_64-devuan31 460 x86_64-devuan40 455 x86_64-dragonflybsd543 460 x86_64-dragonflybsd562 460 x86_64-dragonflybsd583 460 x86_64-dragonflybsd59b 460 x86_64-dragonflybsd59c 460 x86_64-dragonflybsd60 460 x86_64-fedora32 460 x86_64-fedora33 455 x86_64-fedora34 462 x86_64-linux 455 x86_64-linuxmusl 460 x86_64-mabox21 454 x86_64-openindiana 460 x86_64-opensusejump 460 x86_64-opensusetw 460 x86_64-oracle79 461 x86_64-oracle8 458 x86_64-pc-solaris2.11 460 x86_64-slackware15 451 x86_64-solaris 460 x86_64-ubuntu2004 460 x86_64-ubuntu2104 460 x86_64-void-musl Total: 85 systems Missing binaries [compared to x86_64-ubuntu2004]: aarch64-linux : xasy alpha-debian11 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc amd64-freebsd : amd64-freebsd120 : tex2xindy texindy xindy xindy.mem xindy.run amd64-freebsd121 : tex2xindy texindy xindy xindy.mem xindy.run amd64-freebsd122 : tex2xindy texindy xindy xindy.mem xindy.run amd64-freebsd13-clang : xml2pmx amd64-freebsd13-gcc : amd64-netbsd : asy amd64-openbsd64 : luajittex mfluajit mfluajit-nowin xml2pmx amd64-openbsd65 : asy luajittex mfluajit mfluajit-nowin xasy amd64-openbsd66 : asy luajittex mfluajit mfluajit-nowin xasy amd64-openbsd67 : amstex asy cslatex csplain dvilualatex dvilualatex-dev dviluatex eplain etex jadetex latex latex-dev lollipop luacsplain luajittex lualatex lualatex-dev man mex mfluajit mfluajit-nowin mllatex mltex optex pdfcslatex pdfcsplain pdfetex pdfjadetex pdflatex pdflatex-dev pdfmex pdfxmltex platex platex-dev texsis uplatex uplatex-dev utf8mex xasy xelatex xelatex-dev xmltex amd64-openbsd68 : asy luajittex mfluajit mfluajit-nowin xasy amd64-openbsd69-clang : asy luajittex mfluajit mfluajit-nowin xasy armhf-linux : i386-freebsd : i386-linux : i386-linux-void : tex2xindy texindy xindy xindy.mem xindy.run i386-netbsd : asy xasy i386-solaris : tex2xindy texindy xindy xindy.mem xindy.run i686-void32m : cfftot1 dvigif dvilualatex dvilualatex-dev dviluatex dvipdfm dvipdfmx dvipdft dvipng dvisvgm ebb extractbb luacsplain luahbtex luajithbtex luajittex lualatex lualatex-dev luatex mmafm mmpfb optex otfinfo otftotfm t1dotlessj t1lint t1rawafm t1reencode t1testpage ttftotype42 upmendex xdvi xdvi-xaw xdvipdfmx xml2pmx i86pc-solaris114 : xml2pmx m68k-debian11 : asy luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xasy ppc64be-centos7 : luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc xindy xindy.mem xindy.run ppc64le-centos8 : luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc xindy xindy.mem xindy.run ppc64le-debian10 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc ppc64le-debian104 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc ppc64le-debian106 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xml2pmx riscv64-freebsd14 : asy luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc xasy xindy xindy.mem xindy.run riscv64-ubuntu2004 : asy luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xasy s390x-ubuntu2004 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xindy.mem sparc-debian11 : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc universal-darwin : xindy.mem x86_64-centos5 : amstex cslatex csplain dvisvgm eplain etex jadetex latex latex-dev lualatex lualatex-dev mex mllatex mltex pdfcslatex pdfetex pdfjadetex pdflatex pdflatex-dev pdfmex pdfxmltex texsis utf8mex xelatex xelatex-dev xmltex x86_64-centos6 : asy xasy x86_64-darwinlegacy : pdfclose pdfopen xdvi xdvi-xaw x86_64-dragonflybsd543 : tex2xindy texindy xindy xindy.mem xindy.run x86_64-fedora34 : tex2xindy texindy xindy xindy.mem xindy.run x86_64-linux : x86_64-linuxmusl : asy tex2xindy texindy xasy xindy xindy.mem xindy.run x86_64-openindiana : luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc x86_64-oracle8 : x86_64-pc-solaris2.11 : asy luajithbtex xasy x86_64-solaris : luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc xindy xindy.mem xindy.run
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.
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), BlackArch, ClearLinux, CentOS Stream, Fedora Rawhide (fedorarh), GUIX, Hyperbola, Kaisen, Kali, Kaos, PCLinuxOS (pclinuxos), 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/2021/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/2021/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 and CentOS 8, but also on Alma, Debian, Devuan, openSUSE, Red Hat, Rocky, Scientific Linux, 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, 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-2021.csh ### ash, bash, dash, ksh, pdksh, sh, and sh login shells ### (POSIX-compliant, or supersets thereof) . $prefix/skel/SYS.texlive-2021.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 2021 release first, ahead of any local, older TeX Live, or vendor-supplied installations of TeX.
An installed TeX Live 2021 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 2021 DVD image, which allow you to choose subsets for your local installation.
Building TeX Live 2021 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 2021 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 most of the time.
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 mirror 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 mirror 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.
The official description of installing the TeX Live 2021 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-20210226 ### 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_000 subdirectories and 215_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 (previous year) installation are:
Every few days, I update my TeX Live 2021 pre-test installation tree like this on my CentOS 7 workstation:
$ PATH=/path/to/texlive/2021/bin/x86_64-linux-centos-7:$PATH $ export PATH ### Update TeX Live Manager itself (this usually does nothing) $ tlmgr update --self ### Update TeX Live 2021 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/2021/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 Saturday, 07-Dec-2024 10:23:45 MST .
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.
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 2370
directories, 29_500 files, 270 Makefiles,
and 85 GNU-style configure scripts. The binary
subdirectory for each platform contains up to 460
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 2021!
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.
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 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 2021 contains more than 2300 directories and more than 230 Makefiles. I have been able to use both compiler families for building TeX Live 2021 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.
This major section contains reports of the TeX Live 2021 build experience on numerous platforms, in alphabetically ordered subsections: just scroll down to any that are of interest to you.
Here are links to the contents of this section:
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 two new distributions, AlmaLinux (released 31-Mar-2021) and Rocky Linux (released 1-May-2021), that plan to continue the practice of multiyear stability of the GNU/Linux operating system.
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.
The AlmaLinux kernel version is 4.18, matching that currently on CentOS 8 and 8 Stream. The gcc and clang compiler versions on AlmaLinux are 8.3.1 and 10.0.1, slightly behind the versions 8.4.1 and 11.0.0 on CentOS 8.
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. After a user reported in mid-2020 that xindy is missing from the x86_64-linuxmusl binary package, I supplied him binaries for xindy from Void Linux. However, that did not work because of shared library differences with Alpine Linux.
The major impediment to building a full TeX Live 2021 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, and on Alpine 3.12.3 in 2021. On the latter, the default compiler family is gcc-9.3.0.
Further tests show 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.
Alpine Linux 3.13 was released on 14-Jan-2021. Two days later, I successfully built a new VM for it, installed a large collection of packages, built and installed libsigsegv and Clisp from source code, and then successfully completed a TeX Live 2021 build, including Asymptote.
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 2021, the Linux kernel version is 5.5.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 2019. The build of TeX Live 2021 and Asymptote from the texlive-20210106 snapshot, and a later one from texlive-20210317, 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 2021 binaries.
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.
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. This year, surprisingly, saw some improvements: only Asymptote is not buildable.
Because we intend to retire our few remaining CentOS 6 desktops, and repurpose their servers, by summer 2021, I do not want to spend time trying to resolve build problems for this operating system, but I will continue to make build attempts if major TeX Live 2021 source changes are made.
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, but a build with the texlive-20210317 snapshot was successful, once I removed the C++ compiler option -static-libstdc++: that library is not available.
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 2021, 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.
One of the earliest builds at Utah for TeX Live 2021 was on CentOS 7.9 (a free subset of the commercially supported Red Hat 7.9). The previous year's build script, with the year updated, was used, and the build failed in the icu Unicode support library due to C++ issues with static libraries.
A problem report on the developer list was quickly answered with news that a workaround had been found in recent years (but had never been necessary at Utah), and required only the addition of a configure-time option.
The build script was easily updated to use that option on CentOS 7 systems, and a fresh build, including Asymptote, ran flawlessly, using the locally installed gcc-7.5.0 compilers. The native g++ compiler on CentOS 7 is the 2015-vintage g++-4.8.5, which is too old to support the ISO C++ 2014 Standard whose features are used in some of the libraries that are compiled in TeX Live builds.
The TeX Live 2021 build on a PowerPC64 little-endian operating system went like that on the big-endian system described in the preceding section, and the Asymptote build failed for the same reason. A build of Asymptote from a later snapshot succeeded after removal of the C++ compiler option, -static-libstdc++. The Lua JIT programs are missing, because they are not supported on that architecture. The native compilers are from the gcc-8.3.1 family.
The TeX Live 2021 build with native compilers (gcc-8.3.1) on CentOS 8 was flawless, and the extra option needed on CentOS 7 is not required.
The TeX Live 2021 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.
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 1992, 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 build, including Asymptote, with native compilers (gcc-10.2.1) on Debian 11 (code name bullseye) on Alpha was then successful. The Lua JIT programs are not supported on that architecture.
The TeX Live 2021 build with native compilers (gcc-10.2.1) on Debian 11 (code name bullseye/sid) on ARM64 (also known as aarch64) was problem free.
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.
The TeX Live 2021 build with native compilers (gcc-10.2.1) with the texlive-20210413 snapshot on Debian 11 (code name bullseye) on SPARC64 was almost problem free. I had to create symlinks from source/Work/texk/web2c/*.h to source/Work/texk/web2c/mplibdir to repair a missing header file problem. Once that was done, the build, including Asymptote, succeeded.
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.
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 2021 was successful on a newly-released Devuan 3.1 (beowulf) system, and also on a Devuan 4.0 (chimaera) VM.
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 2021, 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.0, in April 2021.
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 29_000 packages at release 6.0), including the latest development versions of gcc 4.x to 11.x, as well as clang versions from 6.x to 11.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 2021 binaries, but only for the most recent versions of DragonFlyBSD. The first, for DragonFlyBSD 5.8.3, was built from a texlive-20210106 snapshot on a VM using the native Clisp. Builds for DragonFlyBSD 5.4.3, 5.6.2, 5.9, and 6.0 also succeeded.
Fedora is the freely accessible development branch of the commercial Red Hat Linux. A build of TeX Live 2021 with gcc-8.3.1 compilers was successful.
The TeX Live 2021 build on Fedora 32 x86 with the native gcc-8.3.1 compilers was problem free.
The TeX Live 2021 build on Fedora 32 x86_64 with the native gcc-10.2.1 compilers was problem free.
Fedora 33 appeared in October 2020, and is the latest stable release of the freely accessible development branch of the commercial Red Hat Linux.
RISC-V is a family of open standard instruction set CPU designs developed starting in 2010 by a research group at the University of California, Berkeley, with many collaborators from other institutions. The latest edition of the famous Computer Architecture books by John Hennessy and David Patterson devotes considerable space to the motivation for, and design of, the RISC-V family, and David Patterson and Andrew Waterman describe it in detail in their book The RISC-V Reader: An Open Architecture Atlas .
Although off-the-shelf desktop computers with a hardware RISC-V CPU are not yet readily available, there are numerous efforts in that direction, recorded here.
You can, nevertheless, run complete operating systems on software emulations of RISC-V, including FreeBSD, NetBSD, and the Linux distributions Debian, Fedora, Gentoo, Janus, OpenMandriva, openSUSE, and Parabola.
In a few hours, I was able to create, configure, and do numerous binary package installations on, a Fedora 32 (Rawhide) RISC-V64 virtual machine, following clear instructions available here. It runs on my personal workstation, which is bootable to several different operating systems, currently Fedora 33 (Rawhide). The workstation CPU is an Intel Xeon Platinum 8253, and the virtual machine runs under virt-manager QEMU/KVM.
Because every RISC-V instruction must be emulated, the machine runs several times slower than one that is natively x86_64, but the performance is nevertheless surprisingly decent. Tests on the x86_64 host versus the RISC-V guest compiling a large mathematical library serially, then in parallel with 2, 4, 8, ..., 256 processes, showed that the emulated virtual machine runs 15 to 30 times slower.
In early 2021, there are about 50_500 packages available in the Fedora 33 RISC-V64 system, compared to about 56_500 for Fedora 33 x86_64. On Fedora RISC-V64, the package system supplies several versions of the gcc and clang compiler family, plus clisp, emacs, go, and TeX Live 2020. The system supports 8-, 16-, 32-, 64-, and 128-bit two's-complement integer types, and 32-, 64-, and 128-bit IEEE 754 binary floating-point types. Addressing is little-endian. The preprocessors for the C and C++ compilers define the symbol __riscv on this architecture.
In build scripts, and the SYS.texlive-202[01].* scripts, I had to add test cases for the model architecture symbol riscv64 produced by the uname -m command, but apart from that, the build of TeX Live 2020, excluding Asymptote, was uneventful. Asymptote, however, does not build because it downloads other packages whose config.guess scripts are too old to recognize the RISC-V architecture. However, for TeX Live 2021, several build attempts on this systems all fail with C++ errors in the ICU library tree.
A build of TeX Live 2021 with the native gcc-10.2.1 compiler family was flawless.
A build of TeX Live 2021 on Fedora 34 (beta prerelease) with the native gcc-11.0.0 compiler family was flawless.
The TeX Live 2021 build with the native GNU compilers (gcc-7.3.0) on FreeBSD 10.4 AMD64 (= x86_64) was problem free.
The TeX Live 2021 build with the native GNU compilers (gcc-9.3.0) on FreeBSD 11.4 AMD64 (= x86_64) was problem free.
The TeX Live 2021 build with the native GNU compilers (gcc-9.3.0) on FreeBSD 12.4 AMD64 (= x86_64) was problem free.
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.
On 6 January 2021, The TeX Live 2021 build with the native GNU compilers (gcc-9.3.0) on FreeBSD 13 AMD64 (= x86_64) was problem free.
A separate build with the native LLVM Clang compilers (clang-9.0.1) was also successful. Consequently, two binary distributions are available for this system.
However, between January and March, I did system upgrades on the FreeBSD 13 VMs, and built fresh VMs as new ISO images were produced in preparation for the official 13.0 release. Sadly, most build attempts with multiple versions of both clang and gcc family compilers failed. Finally, with the FreeBSD-13.0-RC3 ISO images, I created a fresh VM on which a gcc build of TeX Live 2021 was successful. The clang builds all still fail with C++ errors.
On 13 April 2021, FreeBSD 13.0 was officially released, after two years of testing. That day, I created a fresh virtual machine for it, and then successfully built all of TeX Live 2021 with both gcc-8.4.1 and clang-11.0.1 compiler families, after making minor tweaks to the build scripts. The new binary archives are available here (gcc) and here (clang).
Release notes for FreeBSD 13.0 report that RISC-V64 is now a Tier 2 platform for which virtual machine disk images are available. I was unable to build a working VM using QEMU on Ubuntu 20.04 x86_64: the boot hangs. However, a build of the RISC-V64 VM inside the FreeBSD 13.0 AMD64 VM was successful, and I was able to configure inbound and outbound networking for it.
Unfortunately, when I ran the pkg command to begin the long list of required package installations, it tried to access a nonexistent package repository. Thus, until the package system supports FreeBSD on RISC-V64, it is not practical to attempt a TeX Live 2021 build. The pkg command suggests using the FreeBSD ports system to build packages from source code, but that is not reasonable for the number of packages that I need, and would be intolerably slow in a virtual machine where the CPU instruction set is emulated in software. Perhaps next year, ….
The official FreeBSD 13.0 release on 13 April 2021 proved stable for the x86_64 architecture, so a week later, I created another VM for that release for the Intel 32-bit platform, known as i386, i586, i686, or x86 on various systems, and called i386 by FreeBSD 13.0.
A build of a texlive-20210413 snapshot with the gcc-8.4.1 compiler family was successful, apart for a single issue in the build and validation of Asymptote. That reported an inability to recognize the ghostscript version, and requested setting of the ASYMPTOTE_EPSDRIVER environment variable to the value eps2write for versions 9.14 or later (the native version is 9.52 on this system). I did that, but the single test still failed with the same complaint. The test code invokes texpath("A") to get the geometric path of the label argument. On x86_64, that function returns a two-element array (passing the test), but on i386, the result is an empty array (failing the test). All other tests passed, so I installed the asy executable.
It is unclear why that single test failed: a search of the asymptote source tree finds mention of ASYMPTOTE_EPSDRIVER in only two documentation files, plus the single test file. Perhaps the test is now obsolete; it was added in 2016 to version 2.37.
A build attempt with the native clang-11.0.1 compiler family (used to compile the FreeBSD kernel and binary packages) failed, but with more tweaks to the build variables, could likely be made to work. There is a discussion of clang issues elsewhere in this document.
On 11 March 2021, I found that an ISO image was available for FreeBSD 14.0, the development system that is to follow the official 13.0 release that finally appeared on 13 April 2021. As with several versions of 13.0, builds of TeX Live 2021 repeatedly failed on 14.0 with multiple versions of both clang and gcc compiler families. After system and compiler updates, I finally got a build with gcc-8.4.1 compilers to complete for TeX Live 2021, including Asymptote.
When the operating system, installed packages, and the TeX Live source tree are in a state of continual updates, it is often hard to figure out just where the build problems are. The frustrating experience this year for FreeBSD 13 and 14 has been anomalous, because for several years, builds on FreeBSD systems have generally worked if the same TeX Live source tree could be built on major Linux systems.
Release notes for FreeBSD 13.0 report that RISC-V64 is now a Tier 2 platform for which virtual machine disk images are available. A build of a RISC-V64 VM for FreeBSD 14.0 was successful, and I was able to configure inbound and outbound networking for it.
Clisp is not yet available in the FreeBSD 14 package system for this architecture, and I have not yet built a local copy of Clisp, so xindy did not build. The Lua JIT programs are not supported on RISC-V64. Asymptote failed to build because of an undefined symbol, ALIGNMENT, that is used in finalize.c in the gc-8.0.4 subdirectory. Apart from those, the rest of TeX Live 2021 built successfully.
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, and 13, corresponding to those versions in FreeBSD. The binary software package systems for HardenedBSD contain from 28_500 to 29_800 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, and version 11 in 13.0. Versions of the gcc family are available as optional packages; their defaults are 6.4.0 in 11 and 12, and 9.4.0 in 13. All of those gcc versions are capable of building TeX Live 2021, and the builds, including Asymptote, succeeded without problems on all four HardenedBSD releases in the section title.
Mabox Linux is a derivative of the Manjaro GNU/Linux distribution, which uses the pacman package manager from ArchLinux. The Linux kernel version is 5.10.15-1, the gcc version is 10.2.0, and the clang version is 11.0.1.
The build of a texlive-20210219 snapshot on Mabox Linux 21.02 was flawless, and so was a rebuild with a texlive-20210317 snapshot.
NetBSD runs on an astonishingly large number of hardware platforms (about 75), and we have in the past run it on amd64 (x86_64), i386 (x86), SPARC, and VAX systems. However, our current NetBSD systems are all on amd64 hardware, and we have machines running NetBSD versions from 5.x to 10.x.
On NetBSD 6.1.5 on amd64, the default C compiler, /usr/bin/gcc is version 4.5.3, and the latest version in the binary package system, /usr/pkg/gcc49/bin/gcc, is version 4.9.4 (2015). Both are too old for TeX Live 2021, but as an experiment, I forced the build to completion, ignoring errors, with make -i -k world. That produced 333 executables, but among the missing ones are all TeX-based programs. Thus, no binary package is provided for this operating system, which was first released in October 2012. The only NetBSD versions still supported by the NetBSD team are 8.0 and later.
The TeX Live 2021 build on NetBSD 9.1 amd64, including Asymptote, was flawless. The native compiler families is gcc-7.5.0. Builds were also successful on NetBSD 7.2 (with an additional package that provides gcc-7.4.0, because the native gcc-4.8.5 compilers are too old), and on NetBSD 8.2 (gcc-5.5.0 compilers).
On NetBSD 6.1.5, the latest compiler version available is gcc-4.9.4, and that is too old to compile some of the TeX Live 2021 code.
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 the main part of TeX Live 2021 with the native gcc-8.3.0 compiler release was successful. Asymptote built as well, but its test suite hung several times: a top display showed no activity, so it looks like tests are waiting for some event, without using CPU time. The asy executable is included in the binary distribution from this system.
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 6.8 (October 2020), plus a development snapshot for the not-yet-released 6.9 (March 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.
The default build on OpenBSD 6.8 x86_64 with native GNU compilers failed because they are far too old: gcc-4.2.1 from 2007. A restart with the native LLVM Clang compilers (version 10.0.1) produced a successful build of all but Asymptote.
The OpenBSD 6.8 package system has gcc-8.4.0 and g++-8.4.0 compilers, which are installed under the names egcc and eg++. There is no provision for more than two gcc versions, a feature offered now by many other O/S distributions. However, build attempts with those gcc family compilers failed with C++ errors in the teckit subdirectory.
Much of Asymptote compiled with the Clang compilers on OpenBSD 6.x, but eventually, compilation errors terminate the builds. The issue will be reported to the code's author.
Builds for OpenBSD 6.4, 6.5, 6.6, and 6.7 were partially successful, but more work needs to be done to resolve the several missing executables.
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. The default 32-bit build of TeX Live 2021, including Asymptote, was completely successful.
The build of a 64-bit version of TeX Live 2021 on an OpenIndiana VM created from the 5-Apr-2021 ISO image was successful, including Asymptote.
The *luajit* executables cannot be created because the Makefile that is used to generate them requires the -m32 option, which conflicts with the global -m64 option.
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 2021 build with the native gcc-7.5.0 compilers was flawless.
The TeX Live 2021 build on openSUSE Tumbleweed x86 with the native gcc-10.2.1 compilers was flawless.
The TeX Live 2021 build on openSUSE Tumbleweed x86_64 with the native gcc-10.2.1 compilers was flawless.
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.
The main TeX Live 2021 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.
Peppermint 10 is a Linux distribution derived from Debian 10 (code name buster/sid) and Ubuntu 18.04 (code name bionic/beaver). The build of TeX Live 2021 with the native gcc-7.5.0 compiler family was completely successful.
Slackware Linux is one of the earliest GNU/Linux distributions, first created in 1993. The current stable version is 14.2, with a development channel (-current) for 15.0.
The TeX Live 2021 build on a new Slackware 15.0 virtual machine from a texlive-20210219 snapshot was flawless, as was a rebuild with a texlive-20210317 snapshot. The Linux kernel version is 5.10.17, gcc is version 10.2.0, and clang is version 11.1.0.
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 2021 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.
QEMU disk images for Ubuntu 20.04 and 21.04 on RISC-V64 first appeared in mid-April 2021, but despite multiple attempts, I was unable to get either to run on my Ubuntu 20.04 x86_64 workstation.
On 29 June 2021, I tried again with newer disk images for Ubuntu 20.04 and 21.04. The 21.04 one still does not work for me, but I was able to extend the 20.04 disk image (EXT4 filesystem format) with truncate -s +80G, and after several experiments running qemu-system-riscv64 directly, rather than through virt-manager, I was able to get a working virtual machine that I could configure with user accounts and install needed packages on. I then began work on porting my own software, and TeX Live 2021, to that system.
As of July 2021, development motherboards with physical RISC-V64 CPUs are available in limited quantities from SiFive, but no hardware vendor yet appears to offer a standalone RISC-V64 workstation that can be plugged in and booted into a usable operating system. The HiFive Unmatched board from SiFive has a System-on-a-Chip (SoC) iFive Freedom U740 CPU, but only 16GB DRAM soldered-on memory (much like early Apple M1 systems for macOS). That amount of memory may be adequate for a single novice user workstation, but is far too little for my own applications. Thus, QEMU emulation is the only current way to access this relatively new CPU architecture.
Most Debian and Ubuntu package distributions include Clisp, but that for Ubuntu on RISCV-64 does not. Fortunately, the Clisp build recipe recorded earlier for DragonFlyBSD worked flawlessly, after I installed the needed libraries from the package system.
The preprocessors for the C and C++ compilers define the symbol __riscv on this architecture, along with 11 others with that substring to characterize optional features of RISC-V64. Because of early decoding of instruction bits, the RISC-V64 instruction set architecture requires little-endian addressing for instruction storage, but permits extensions for big-endian addressing for data. It seems unlikely to me that mixed-endian designs will be produced. Fedora, FreeBSD, and Ubuntu on RISC-V64 are entirely little-endian.
Except for the Lua JIT programs, which are not supported on RISC-V64, and Asymptote, the build completed succesfully. Asymptote does not build because it downloads other packages whose config.guess scripts are too old to recognize the RISC-V architecture.
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 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 2021 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 2021, 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.
The TeX Live 2021 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.
The TeX Live 2021 build with native compilers (gcc-10.3.0) on Ubuntu 21.04 (code name Hirsute Hippo) on x86_64 was problem free.
The TeX Live 2021 build with native compilers (gcc-9.3.0) 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.
The build attempt of TeX Live 2021 0n the 32-bit companion of the 64-bit Void Linux system showed problems: the zziplib compilation exposes a 64-bit off64_t type that does not apply to this platform.
This turns out to be a red herring: the fault is that the default command shell, /bin/sh, is a link to dash, which behaves somewhat differently to other members of the Bourne-shell family. In particular, the zziplib build uses ASCII control characters to delimit command-line patterns, and that fails with dash. That in turn produces incorrectly generated files that later fail compilation.
The solution is a modification of my build-texlive-2021.sh script to force use of bash for the CONFIG_SHELL. Once I did that, and installed several previously missing packages, the build of all of TeX Live 2021, including Asymptote, was successful. I had made a similar change in some past year for 64-bit Void Linux builds, but had forgotten to make a corresponding change for 32-bit Void systems.