| Updates for TeX Live 2019 were officially frozen on 28 February 2020. Work is now in progress to prepare the TeX Live 2020 release. You can find information on downloading the older release here. Once you have run the update procedure described there, you need not do so again: you have the final state of the 2019 software. |
Original version:
Mon Dec 23 16:39:07 2019
Last updates:
...
Sat May 16 17:47:38 2020
This directory contains files created in support of building and using a pre-release of the TeX Live 2020 distribution. That release was officially made on 6 April 2020, and is expected to be available on DVD in mid-summer 2020; 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 clicking on 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/texcol2020.iso /mnt
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-2020.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 2020 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, and 2020 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 16 May 2020, the following builds have been successful by the TeX Live team, or at Utah:
% show-file-counts.sh
453 aarch64-linux
452 amd64-clonos19
454 amd64-clonos19-12
454 amd64-clonos19-13
455 amd64-freebsd
455 amd64-freebsd113
455 amd64-freebsd113-static
455 amd64-freebsd121
453 amd64-freebsd13
454 amd64-freebsd13-clang
455 amd64-freebsd13-gcc
452 amd64-freebsd130
456 amd64-furybsd12
454 amd64-ghostbsd1910
454 amd64-ghostbsd20
454 amd64-ghostbsd2002
454 amd64-hardenedbsd11
454 amd64-hardenedbsd111
455 amd64-hardenedbsd12
454 amd64-hardenedbsd121
455 amd64-hardenedbsd13
454 amd64-netbsd
455 amd64-netbsd100
455 amd64-netbsd70
455 amd64-netbsd702
455 amd64-netbsd711
455 amd64-netbsd712
455 amd64-netbsd72
455 amd64-netbsd80
455 amd64-netbsd81
455 amd64-netbsd90
452 amd64-openbsd62
449 amd64-openbsd64
451 amd64-openbsd65
452 amd64-openbsd66
454 armhf-linux
455 armv7l-arch
454 i386-centos732
454 i386-fedora28
453 i386-freebsd
455 i386-freebsd113
450 i386-freebsd121
454 i386-freebsd13
455 i386-linux
452 i386-netbsd
454 i386-opensusetw
452 i386-pc-solaris2.11
450 i386-solaris
448 ppc64le-linux
446 riscv64-fedora32
455 x86_64-alpine311
452 x86_64-arco19
455 x86_64-arco20
455 x86_64-blackarch
452 x86_64-bodhi50
452 x86_64-budgie1910
456 x86_64-centos7
455 x86_64-centos8
455 x86_64-darwin
451 x86_64-darwinlegacy
452 x86_64-debian100
452 x86_64-debian102
454 x86_64-debian11
452 x86_64-debian811
452 x86_64-debian910
455 x86_64-devuan20
452 x86_64-devuan30
455 x86_64-dragonflybsd562
455 x86_64-dragonflybsd58
455 x86_64-dragonflybsd59
454 x86_64-fedora26
454 x86_64-fedora27
454 x86_64-fedora28
454 x86_64-fedora29
454 x86_64-fedora30
454 x86_64-fedora31
454 x86_64-fedora32
454 x86_64-fedora33
454 x86_64-kali-2
454 x86_64-kaos2020
454 x86_64-kubuntu1904
455 x86_64-linux
448 x86_64-linuxmusl
455 x86_64-manjaro19
455 x86_64-mint193
455 x86_64-openmandriva41
455 x86_64-openmandriva41-clang
454 x86_64-opensuse151
454 x86_64-opensuse152
455 x86_64-opensusetw2
454 x86_64-oracle8
454 x86_64-redhat8
455 x86_64-slackware15
444 x86_64-solaris
453 x86_64-solaris211
455 x86_64-trident-void-linux
455 x86_64-ubuntu1510
452 x86_64-ubuntu1610
455 x86_64-ubuntu1710
452 x86_64-ubuntu1810
452 x86_64-ubuntu1910
455 x86_64-ubuntu2004
Total: 102 systems
Missing binaries [compared to x86_64-solaris211]:
aarch64-linux : biber lua2dox_filter xasy
amd64-clonos19 : biber
amd64-clonos19-12 : biber lua2dox_filter
amd64-clonos19-13 : biber lua2dox_filter
amd64-freebsd : lua2dox_filter
amd64-freebsd113 : biber
amd64-freebsd113-static : biber
amd64-freebsd121 : biber
amd64-freebsd13 : biber chklref dvilualatex-dev latex-dev luahbtex luajithbtex lualatex-dev pamphletangler pdflatex-dev platex-dev uplatex-dev xelatex-dev
amd64-freebsd13-clang : biber
amd64-freebsd13-gcc : biber
amd64-freebsd130 : biber
amd64-furybsd12 : biber
amd64-ghostbsd1910 : biber lua2dox_filter
amd64-ghostbsd20 : biber
amd64-ghostbsd2002 : biber lua2dox_filter
amd64-hardenedbsd11 : biber
amd64-hardenedbsd111 : biber lua2dox_filter
amd64-hardenedbsd12 : biber
amd64-hardenedbsd121 : biber lua2dox_filter
amd64-hardenedbsd13 : biber
amd64-netbsd : biber lua2dox_filter
amd64-netbsd100 : biber
amd64-netbsd70 : biber
amd64-netbsd702 : biber
amd64-netbsd711 : biber
amd64-netbsd712 : biber
amd64-netbsd72 : biber
amd64-netbsd80 : biber
amd64-netbsd81 : biber
amd64-netbsd90 : biber
amd64-openbsd62 : biber luajittex mfluajit mfluajit-nowin
amd64-openbsd64 : asy biber luajittex mfluajit mfluajit-nowin xasy
amd64-openbsd65 : biber luajittex mfluajit mfluajit-nowin
amd64-openbsd66 : biber luajittex mfluajit mfluajit-nowin
armhf-linux : biber lua2dox_filter
armv7l-arch : biber
i386-centos732 : biber lua2dox_filter
i386-fedora28 : biber lua2dox_filter
i386-freebsd : asy lua2dox_filter xasy
i386-freebsd113 : biber
i386-freebsd121 : biber tex2xindy texindy xindy xindy.mem xindy.run
i386-freebsd13 : biber lua2dox_filter
i386-linux : lua2dox_filter
i386-netbsd : asy biber lua2dox_filter xasy
i386-opensusetw : biber lua2dox_filter
i386-pc-solaris2.11 : xasy
i386-solaris : lua2dox_filter tex2xindy texindy xindy xindy.mem xindy.run
ppc64le-linux : biber luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xasy
riscv64-fedora32 : asy biber lua2dox_filter luajithbtex luajittex mfluajit mfluajit-nowin texluajit texluajitc xasy
x86_64-alpine311 : biber lua2dox_filter
x86_64-arco19 : biber
x86_64-arco20 : biber
x86_64-blackarch : biber
x86_64-bodhi50 : biber
x86_64-budgie1910 : biber
x86_64-centos7 : biber
x86_64-centos8 : biber
x86_64-darwin : lua2dox_filter
x86_64-darwinlegacy : lua2dox_filter pdfclose pdfopen xdvi xdvi-xaw
x86_64-debian100 : biber
x86_64-debian102 : biber
x86_64-debian11 : biber lua2dox_filter
x86_64-debian811 : biber
x86_64-debian910 : biber
x86_64-devuan20 : biber
x86_64-devuan30 : biber
x86_64-dragonflybsd562 : biber
x86_64-dragonflybsd58 : biber
x86_64-dragonflybsd59 : biber
x86_64-fedora26 : biber
x86_64-fedora27 : biber
x86_64-fedora28 : biber
x86_64-fedora29 : biber
x86_64-fedora30 : biber
x86_64-fedora31 : biber
x86_64-fedora32 : biber
x86_64-fedora33 : biber lua2dox_filter
x86_64-kali-2 : biber
x86_64-kaos2020 : biber
x86_64-kubuntu1904 : biber lua2dox_filter
x86_64-linux : lua2dox_filter
x86_64-linuxmusl : asy lua2dox_filter tex2xindy texindy xasy xindy xindy.mem xindy.run
x86_64-manjaro19 : biber
x86_64-mint193 : biber xasy
x86_64-openmandriva41 : biber
x86_64-openmandriva41-clang : biber
x86_64-opensuse151 : biber
x86_64-opensuse152 : biber
x86_64-opensusetw2 : biber
x86_64-oracle8 : biber
x86_64-redhat8 : biber
x86_64-slackware15 : biber
x86_64-solaris : lua2dox_filter luajithbtex luajittex mfluajit mfluajit-nowin tex2xindy texindy texluajit texluajitc xindy xindy.mem xindy.run
x86_64-trident-void-linux : biber
x86_64-ubuntu1510 : biber
x86_64-ubuntu1610 : biber
x86_64-ubuntu1710 : biber
x86_64-ubuntu1810 : biber
x86_64-ubuntu1910 : biber
x86_64-ubuntu2004 : biber
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 win32 x86_64-linux
amd64-netbsd i386-linux x86_64-cygwin x86_64-linuxmusl
armhf-linux i386-netbsd x86_64-darwin x86_64-solaris
Most of the others have been built at the University of Utah, almost entirely in facilities of the Department of Mathematics, with an additional build for powerpc64le-centos7 done on a system kindly made available by the Center for High Performance Computing.
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.
ArchLinux (arch), ClearLinux, Fedora Rawhide (fedorarh), GUIX, Hyperbola, Kali, PCLinuxOS (pclinuxos), 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/2020/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/2020/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 Debian, openSUSE, Red Hat, Ubuntu, and other distributions. Similarly, Solaris 10 binaries run just fine on Solaris 11. FreeBSD binaries are often usable on 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-2020.csh
### ash, bash, dash, ksh, pdksh, sh, and sh login shells
### (POSIX-compliant, or supersets thereof)
. $prefix/skel/SYS.texlive-2020.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 2020 release first, ahead of any local, older TeX Live, or vendor-supplied installations of TeX.
An installed TeX Live 2020 tree with all available packages, and binaries for one O/S architecture, requires about 13GB of disk space. It contains about 14_370 directories and 215_500 files. Smaller storage totals are possible with the installer programs in the official TeX Live 2020 DVD image, which allow you to choose subsets for your local installation.
Building TeX Live 2020 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 2020 on the US market, spinning magnetic disks cost about US$25 per terabyte, and solid-state disks (SSDs) cost about US$100 per terabyte. Thus, storage of a full TeX Live 2020 tree costs between US$0.30 and US$1.20, 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, and internal memory (DRAM), 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 2020 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 (4MB) installer bundle
$ wget http://www.math.utah.edu/pub/texlive/tlpretest/install-tl-unx.tar.gz
### 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-20200304
### 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 7083 packages. That step took 71 minutes on a physical machine, or about 100 packages per minute. The installation creates almost 14_000 subdirectories and 200_000 files.
The newly installed tree takes almost 7GB of filesystem space, with executables for 16 platforms in the bin subdirectory. That subdirectory takes 1.6GB of space, so a typical installation with just one platform directory would need about 5.5GB 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 are:
Every few days, I update my TeX Live 2020 pre-test installation tree like this on my CentOS 7 workstation:
$ PATH=/path/to/texlive/2020/bin/x86_64-linux-centos-7:$PATH
$ export PATH
### Update TeX Live Manager itself (this usually does nothing)
$ tlmgr update --self
### Update TeX Live 2020 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/2020/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).
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 almost 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 with about 1500
directories, 17_000 files, 230 Makefiles,
and 80 GNU-style configure scripts. The binary
subdirectory for each platform contains up to 454
programs. The total amount of source code just in the
main languages (Asymptote, C, C++, Java, Lisp,
PostScript, and Web) is about 3_474_000 lines. Programs
in five scripting languages (awk, lua, perl, python, and
shell) contribute another 237_000 lines. In addition,
in the final TeX Live installation tree, there are about
8_247_000 lines of code in the TeX macro language. In
round figures, there are about 11 million lines of
code in TeX Live 2020!
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.
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 x86_64 Linux MUSL. After a user reported 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 2020 system on Alpine Linux is that its binary package system lacks clisp, and the -lffcall and -lsigsegv libraries. 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 2020, and Asymptote, succeeded on Alpine 3.11.6.
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.
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.
The Linux kernel version is 5.4.6-1-ARCH, and the C/C++ compilers available on this system are from gcc version 8.2.0. With them, the build of TeX Live 2020 and Asymptote from the texlive-20200205 snapshot 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 2020 binaries.
Arco Linux is a distribution based on ArchLinux, and like that system, is a rolling release. Its starting version in September 2019 was from an ISO image named arcolinux-lts-v19.09.1.iso. The build of all of TeX Live 2020 was successful. A later build from another VM built from arcolinux-v20.2.12.iso was equally successful.
BlackArch is a distribution based on ArchLinux, and like that system, is a rolling release. Its starting version in August 2019 was from an ISO image named blackarch-linux-live-2019.09.01-x86_64.iso. The build of all of TeX Live 2020 was successful.
Bodhi Linux is based on Ubuntu 18.04.3 LTS (Bionic Beaver). It was installed in October 2018 from an ISO image named bodhi-5.0.0-64.iso. The build of all of TeX Live 2020 was successful.
Budgie is a distribution based on Ubuntu 19.10 (Eoan Ermine). Our Budgie machine has a ZFS filesystem, a feature that finally became available for Ubuntu Linux in late 2019. The build of all of TeX Live 2020 was successful.
A build of a texlive-20200124 snapshot on CentOS 7.7.1908 (the free, and unsupported, companion of Red Hat 7), including Asymptote, ran flawlessly and is in daily use at our site. It did, however, require prior builds from source code of Clisp, and of the gcc-6.5.0 compiler family, because the native compiler, /usr/bin/gcc, is version 4.8.5, which is too old to support C++ features required in parts of TeX Live 2020.
Later builds on both 32-bit and 64-bit CentOS 7 systems from a texlive-20200320 snapshot succeeded.
CentOS 8 is a major release of the free, but unsupported, subset of the commercial Red Hat Linux distribution, and it appeared more than five years after CentOS 7. There are three significant changes from 7 to 8:
The first does not affect ordinary users, but the second has long been a big barrier to software portability, particularly because the C++ language level required by many modern packages (including several needed by TeX Live) is not supported by the 4.x compilers. Consequently, at our site, we have built hundreds of versions of the GNU Compiler Collection, so that our users have a choice of many compilers and levels of language support for Ada, C, C++, D, Fortran, Go, Java, Objective-C, and Objective-C++. In addition, the C compiler is built with support for decimal floating-point arithmetic on every platform for which the compiler can provide that feature.
CentOS 8.1 has about 13_300 available prebuilt packages that can be easily installed with dnf install pkgname. However, as with previous Red Hat releases, and other distributions based on them, there is no support for any Common Lisp compiler. Only GNU guile, which supports the Scheme derivative of Lisp, is in the Red Hat package system. Consequently, before I could attempt to build TeX Live, I first had to build and install Clisp version 2.49.92.
Two other serious issues have been found in CentOS 8, Oracle 8, and Red Hat 8:
There is a bug in the /etc/csh.cshrc script: it runs /etc/profile.d/lang.csh, and that script uses the undefined variable TERM and terminates with a fatal error. Our local fix repairs that problem by adding a statement set TERM=xterm near the start of /etc/csh.cshrc. The impact of that bug is horrid: it terminates shell startup processing, and all user customizations are lost. For us, that completely destroyed the possibility of starting automated software builds via ssh connections for users who prefer the tcsh login shell (a decades-long default at our site). We do many thousands of such builds every month.
I reported the bug to the CentOS developers, who after a long time responded that that would not fix it, because the fault lies with Red Hat. However, Red Hat won't fix it because we don't have a service contract with them, and thus we are not permitted to report bugs to them!
The package libstdc++-static, available with CentOS 7 and earlier releases, is missing in Red Hat 8 and derivatives. It contains the static library libstdc++.a that is needed to support the g++ compiler's -static-libstdc++ option. The C++ library evolves rapidly, and is a major stumbling block for developers who wish to distribute compiled software. If they link with the shared C++ library, then a subsequent update to the compiler will introduce a new shared library that is likely incompatible with the previous one, preventing programs linked against the old one from running. Our solution is to request static linking, so that the C++ library code is embedded in the executables.
This error too will not be repaired by CentOS because the fault lies with Red Hat, and we cannot report it to them.
I found that if the gcc-toolset-9 package is installed, it creates a separate directory tree under /opt/rh, and that tree has gcc version 9.1.1 compilers, and the needed static C++ libraries. Thus, by setting the CC and CXX shell variables at build time to point to the newer compilers, I got a successful build of TeX Live 2020, including Asymptote.
A later build from a texlive-20200320 snapshot succeeded on the CentOS 8 system with the gcc version 9.1.1 compilers.
ClonOS 19 is a derivative of FreeBSD 12.0 and 13.0, with a goal of supporting both Xen and Bhyve hypervisors on the same system. On Linux systems, where VirtManager (QEMU/KVM), OVirt, and VirtualBox are available virtualization layers, only one of them can be installed at a time. The native TeX system on ClosOS is old: TeX Live 2015.
A build of all of TeX Live 2020 was successful on the ClonOS system based on FreeBSD 13.0.
Debian (named after its founders, Debra Lynn and Ian Murdock) is one of the earliest, and largest, Linux distributions, with more than 65_000 software packages in the latest releases used here. Builds of all of TeX Live 2020 were successful on Debian 8.11, 9.10, 10.0, 10.2, and 11.0 (prerelease) systems.
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 2020 was successful on Devuan 2.0 (ascii) and 3.0 (beowulf) systems.
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.
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, 5.9, in February 2020.
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 31_000 packages at release 5.9), including the latest development versions of gcc 4.x to 10.x, as well as clang versions from 6.x to 9.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 2020 binaries, but only for the most recent versions of DragonFlyBSD. They were rebuilt on 5.6.2 from a texlive-20200205 snapshot on a newly installed physical machine on 06 February 2020, using the native Clisp. A later build on 5.9 from a texlive-20200226 snapshot was problem free. Those builds have all since been updated to a texlive-20200307 snapshot.
Fedora is the development channel for the commercial Red Hat Enterprise Linux. Fedora 26 appeared in July 2017, 27 in November 2017, 28 in May 2018, 29 in October 2018, 30 in April 2019, and the latest, 31, in October 2019. The Fedora 31 Linux kernel is version 5.4, well ahead of the kernels on Red Hat, CentOS, and other distributions of that family. The default compiler family on Fedora 26 and 27 is gcc-7.3.1 from early 2018, on 28 and 29, gcc-8.3.1 from early 2019, and on 30 and 31, gcc-9.2.1 from mid-2019.
Builds of TeX Live 2020 on Fedora 26, 27, 28, 29, 30, and 31 from the texlive-20200201 source tree were uneventful, and everything built as expected, including Asymptote.
Builds on a newly installed physical machine running Fedora 33 (Rawhide) from the texlive-20200318 and texlive-20200327 snapshots were similarly successful.
The rolling release version of Fedora Linux is called Rawhide, and at some point, it is designated the latest numbered release, and development continues with a new Rawhide. The main compiler family is gcc version 10.0.1 20200130, with clang version 9.0.1 available as an extra installable package. The Linux kernel version is 5.5.
The compiler change broke the TeX Live 2020 build, because the gcc version 10 C and C++ compilers alter the default behavior for duplicate external variable declarations. Under previous major versions, if a top-level declaration int k; appears in multiple files, it is assumed to be common to all of them. Now each such variable is assumed to have a different storage location, and there is then a link-time error from duplicate global names in different locations. The change is documented here. I first noticed this in a posting to the pcc compiler development list that I follow, and later that same day, I hit that problem on Fedora 32 in building the autosp tool (for music typesetting).
The quick first fix seemed to be restart the build in the source/Work directory with make CFLAGS=-fcommon CXXFLAGS=-fcommon world. That works in some directories, but in others, compilation terminates because of the change in compiler flags.
The next try was a fresh build with the two options attached to compiler names, as with CC="gcc -fcommon" and CXX="g++ -fcommon", but that too fails because code somewhere in the build incorrectly assumes that each of those variables expands to a single pathname.
I got a successful build of all of TeX Live 2020 by creating two wrapper scripts whose pathnames are used for the values of the CC and CXX shell variables in the build-script invocation:
% cat xgcc
#! /bin/sh -
/usr/bin/gcc -fcommon "$@"
% cat xg++
#! /bin/sh -
/usr/bin/g++ -fcommon "$@"
Eventually, the TeX Live code components with duplicate common external variables must be corrected, but for now, my wrapper scripts do the job.
To test C and C++ code for such flaws with earlier releases of gcc, simply add the -fno-common option.
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.
There are about 44_000 packages available in the Fedora RISC-V64 system, compared to about 60_000 for Fedora x86_64. On Fedora RISC-V64, there are several versions of the gcc and clang compiler family, plus clisp, emacs, go, and TeX Live 2019. 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-2020.* 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.
On 23 December 2019, I installed on a new x86_64 physical machine the bleeding-edge development release of FreeBSD 13.0 from an installer image obtained from https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ on 21 December 2019.
After installation and configuration of the base O/S and the X11 window system for both Xfce4 and KDE (Gnome3 was available in FreeBSD 12.1, but is not yet in 13.0), I installed about 1160 binary packages, including clang family compiler versions 6.0, 7.0, 8.0, 9.0, and 10.0, gcc family compiler versions 6.5.0, 7.5.0, 8.3.1 20191129, 9.2.0, and 10.0.0 20191201 (experimental), and Clisp version 2.49.93+. The bootstrap compilers are /usr/local/bin/gcc and /usr/local/bin/g++, both version 9.2.0.
The build scripts build-texlive-2020.sh and build-asymptote.sh then flawlessly built TeX Live 2020 from a source code snapshot downloaded on 23 December 2019.
I installed the binaries in the directory $prefix/texlive/2020/bin/amd64-freebsd130 and packaged them for Web distribution here.
Later builds of more recent TeX Live 2020 source tree snapshots on FreeBSD 11.3 and 12.1 on amd64, and for all three on i386, were similarly successful.
The Asymptote executable, asy, depends on 39 shared libraries on FreeBSD 11.3 amd64. As an experiment, a build of Asymptote from a texlive-20200310 snapshot with -static added to the LDFLAGS variable produced a shared-library-free asy file that, after stripping, is only 2.7MB larger than the one with shared libraries. It is available here. However, the OpenGL library, -lGL, is not available as a static library, so the configure script disables its use. OpenGL support is present in the companion distribution with a dynamically linked asy executable.
It is not practical to do a build of the rest of TeX Live with static linking. The problem is that when shared libraries are used, a reference to a single library can automatically bring in references to many others. With static linking, each such required library must be identified, named, and supplied in the correct order: the source code changes to support that for hundreds of executables are too large for the TeX Live team to contemplate. In addition, if even a single required library is available only in shared library form, which is widely the case on most O/S distributions, then static linking is impossible on many systems.
The preceding section documented a successful TeX Live 2020 build on FreeBSD 13.0 amd64 (x86_64) with the gcc 9.2.0 compiler family.
However, the native C/C++ compilers, /usr/bin/cc and /usr/bin/c++, are from the clang 8.0.1 family. In 2014, at FreeBSD version 10, the developers replaced gcc by clang as the standard compiler for the kernel and other software tools. This is part of a general effort to remove software governed by the GNU General Public Licenses from the base FreeBSD distribution, although many such packages remain available for optional installation from the binary package system.
However, the GNU version of the make utility, gmake, is required to handle several of the 267 Makefiles in the TeX Live 2020 tree. I therefore make it a practice when configuring any new machine to ensure that several GNU packages are always installed, either from the vendor package system, or from source code. They include at least bison, clisp, coreutils, findutils, flex, fontconfig, gcc, gcj, gfortran, gnat, gnupg or gnupg2, libcrypt, libffcall, fontconfig, libintl, sometimes libiconv, libsigsegv, libunistring, m4, make, ncurses, readline, sed, and tar.
A fresh build of TeX Live 2020 with the shell variables settings CC=/usr/bin/cc and CXX=/usr/bin/c++ succeeded, but the subsequent build of Asymptote failed because that package mixes compiler flags for C and C++, and clang and clang++ both complain about unrecognized flags. I applied this small patch to the Asymptote code:
% cd texlive-20200201/source/utils/asymptote
% diff Makefile.in.org Makefile.in
72c72
< OPTS = $(DEFS) @CPPFLAGS@ @CXXFLAGS@ $(CFLAGS)
---
> OPTS = $(DEFS) @CPPFLAGS@ @CXXFLAGS@
With that change, the build and validation of Asymptote succeeded. The resulting TeX Live 2020 binaries are available in the file amd64-freebsd13-clang.tar.xz.
FuryBSD is based on FreeBSD, and can be used as a live image, or installed on a disk partition. It uses the FreeBSD package repository, and once a suitable set of binary packages was installed, the TeX Live 2020 build with the gcc-8.3.1 compiler family completed successfully.
On 30 January 2020, I installed the GhostBSD 20.01 release on a physical machine, a Dell Precision 7920 workstation. The O/S is based on FreeBSD 12.1, and a TeX Live 2020 build from FreeBSD 13.0 appears to work on GhostBSD. Nevertheless, I attempted a build of the texlive-20200130 snapshot on GhostBSD 20.01 using the gcc 8.3.1 C and C++ compilers, and it succeeded, including Asymptote.
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 three versions of HardenedBSD is clang version 5 in 11 and 12, and version 8 in 13. Versions of the gcc family are available as optional packages; their defaults are 6.4.0 in 11 and 12, and 8.3.0 in 13. All of those gcc versions are capable of building TeX Live 2020, and the builds, including Asymptote, succeeded without problems on all three HardenedBSD releases.
Based on the experience described earlier of building TeX Live 2020 on FreeBSD with the clang compiler family, I expect that with similar patching, builds should succeed on the HardenedBSD systems. However, I have not yet tried.
KaOS is an O/S currently based on Arch Linux, but with its own separately built repository of about 4000 binary packages, including TeX Live 2019. Its desktop environment is the KDE Plasma environment. Its Web site notes a possible future move from the Linux 5.4.7-1 kernel to an illumian (OpenSolaris) kernel.
KaOS supplies all of the packages needed to build TeX Live 2020, including clang-9.0.1, CLisp, and gcc-9.2.0, and once scores of needed packages were installed, the build of a texlive-20200214 snapshot, including Asymptote, was flawless.
Manjaro Linux is based on Arch Linux and uses the same package manager, pacman, but the package repositories are unique to Manjaro. Although Manjaro Linux has version numbers recorded in the file /etc/lsb-release, it uses a rolling release model, so major versions can increase during normal software updates.
A virtual machine built on 28 February 2020 from the newly released Manjaro 19 ISO image was somewhat difficult to create, but once we succeeded, only a few dozen binary packages, including Clisp, needed to be explicitly installed to have a suitable base for building TeX Live 2020, and that task was problem free. The Manjaro Linux kernel version is 5.6.0, and the gcc compiler family version is 9.2.1. Clang version 9.0.1 compilers are available, but they were not used for the TeX Live build.
Linux Mint is based on Ubuntu Linux, and the latest Mint version, 19.3, released on 24 December 2019 is derived from Ubuntu 18.04 LTS (Long Term Support). As I expected, a build from a texlive-20200220 snapshot was flawless.
NetBSD runs on an astonishly 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.
The latest official release is NetBSD 9.0 of 14 February 2020. We also have a system that runs the version 10 development release, currently tagged 9.99.46.
Package repositories for NetBSD versions before 7.0 have been removed from the NetBSD archives, so it has not been practical to install the newer compiler versions that are needed to try to build TeX Live 2020 on our NetBSD 5.0.2 and 6.1.5 systems. Their default compilers are gcc-4.1.3 and gcc-4.5.3, respectively, and they lack support for C++-11 and C++-14 features used in some of the recent TeX Live components.
Initial attempts to build TeX Live 2020 on several different NetBSD systems all failed the same way: an unknown datatype locale_t was diagnosed in C++ compilations. That type is certainly used in numerous NetBSD header files for C and C++, but it is not visible by default, because of preprocessor wrappers like this fragment from the standard header file <string.h>:
#if (_POSIX_C_SOURCE - 0) >= 200809L || defined(_NETBSD_SOURCE)
# ifndef __LOCALE_T_DECLARED
typedef struct _locale *locale_t;
# define __LOCALE_T_DECLARED
# endif
Once I added -D_NETBSD_SOURCE to the CXXFLAGS variable in NetBSD builds, they mostly succeeded.
As in previous TeX Live build years, the configure commands require the --disable-dvisvgm option, because the C++ source code for dvisvgm fails to compile on any of our NetBSD versions. On 25 February 2020, the dvisvgm developers supplied a patch that fixed the failure, and a subsequent rebuild on NetBSD 9.0 successfully created that program.
Although we have Clisp installed on all of our NetBSD systems, the TeX Live 2020 build script supplied a --enable-xindy=no option in the NetBSD builds. I redid all of the NetBSD builds with an explicit --enable-xindy option to see whether xindy can be successfully built, and that worked.
Asymptote also failed to compile on NetBSD, because the C++ compilers complain about ambiguous calls to the overloaded function popcount(). Fortunately, the developer found a suitable fix, and as of 04 March 2020, all of the nine versions of NetBSD for which we supply binaries now have a complete set of TeX Live 2020 programs.
TeX Live 2020 binary packages are available for NetBSD 7.0, 7.0.2, 7.1.1, 7.1.2, 7.2, 8.0, 8.1, 9.0, and 10.0 systems on AMD64 here.
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.9 (October 2011) to the latest 6.6 (October 2019), 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 gcc release on OpenBSD 6.6 is rather old: 4.2.1 from mid-2007. There is an optional binary package, gcc-8.3.0p4, but that supplies only a C compiler named egcc; there is no corresponding C++ compiler. Thus, without the substantial work of installing a recent gcc compiler from source code, the only compilers potentially capable of building recent TeX Live releases are /usr/bin/cc and /usr/bin/c++, which are from clang 8.0.1 (mid 2019).
A build of the texlive-20200204 snapshot with the clang compilers mostly succeeded on OpenBSD 6.6. The subsequent build of Asymptote created the executable program, but its validation suite failed with a runaway test:
../asy -dir ../base gs/*.asy
Testing Ghostscript...Hangup
That test was aborted by a manual % kill -HUP command from another window after it ran for more than 90 minutes without terminating. Because most of the Asymptote tests passed, I installed the executable.
The only major missing executables in TeX Live 2020 on OpenBSD 6.6 are those for Lua's just-in-time compilation feature. They cannot be built on OpenBSD, possibly because of its extra default protection that memory pages for program code can be either writable, or executable, but not both. That prohibition eliminates stack-buffer-overrun attacks that have plagued most systems for decades.
The OpenBSD 6.5 C/C++ compilers are the Clang 7.0.1 ones, and the C++ compiler built TeX Live 2020, and Asymptote, but it failed two of the latter's tests:
../asy -dir ../base -config "" -render=0 -f pdf -noprc grid3xyz.asy
../base/plain_Label.asy: 679.23: reading array of length 3 with out-of-bounds index 3
../asy -dir ../base gs/*.asy
Testing Ghostscript...Hangup
However, I decided to include Asymptote in the binary installation for OpenBSD 6.5, because the remaining tests passed.
The OpenBSD 6.4 C/C++ compilers are the Clang 6.0.0 ones, and the C++ compiler could not build Asymptote. However, apart from that, and the Lua just-in-time compilation programs, the TeX Live 2020 build from a texlive-20200208 snapshot succeeded. Similar remarks apply to OpenBSD 6.2, which has the Clang 4.0.0 compilers.
Apostolos Syropoulos in Xanthi, Greece, kindly supplied a distribution of binaries for TeX Live 2020 for Solaris 11 on x86 and x86_64. He reports that they were built on OpenIndiana Hipster 2019.10 (powered by illumos) system that was assembled 02 November 2019, and the builds succeeded without any issues. He also built the 32-bit and 64-bit versions of biber that are included in the binary distributions here.
OpenIndiana was originally a distribution based on OpenSolaris, with a separate rolling-release version called Hipster. However, in 2019, the older distribution was dropped, leaving only Hipster.
Related distributions based on OpenSolaris include DilOS, Dyson, Illumian, OmniTribblix, Tribblix, and XStreamOS. I'm currently testing this build on an Oracle Solaris 11.4 system, where I plan to attempt my own build.
There is another distribution, Unleashed, that is derived from OpenSolaris, but has evolved from that base, and is no longer binary compatible with it. It may be a future TeX Live build platform at this site.
OpenMandriva 4.1 is a new release of 1 February 2020 of a Linux distribution that first appeared in 2013, as a fork of Mandriva Linux (formerly called Mandrake Linux) that began in 1998. OpenMandriva 3.0 in 2016 was the first Linux distribution to be built entirely with the Clang compiler family, rather than the gcc family. In OpenMandriva 4.1, the Linux kernel version is 5.5.2, and the default C/C++ compilers are clang-9.0.1. The gcc-9.2.1 (20191207) compilers are available in the package system.
The package manager is normally the Red Hat dnf tool, but can also be the openSUSE zypper tool.
The binary package repository does not contain Clisp, so the initial TeX Live 2020 build from the texlive-20200220 lacked xindy and related executables. Otherwise, the build was flawless. A subsequent build and installation of Clisp from source, followed by a complete rebuild of TeX Live 2020, were successful. Those builds all use the gcc compilers.
Because OpenMandriva uses the Clang compiler family for its own builds, I felt that it would be useful to attempt a TeX Live 2020 build with that family. Clang had worked for builds on some of the BSD family, so I expected that it would as well on OpenMandriva. Alas, that is not the case, but the fix is easy.
The problem is that the C++ compiler option -static-libstdc++ that we prefer to use in order to isolate executables from frequent incompatible changes to the C++ library works differently with g++ than with c++. In particular, the configure scripts create a short program to test for namespace support. That program compiles and links fine with g++, but with c++, linking fails because there is a reference to -lgcc_s, a library for which there is no static libgcc_s.a file available in the OpenMandriva package system; only libgcc_s.so* shared library files are supplied.
The build fix was to make private versions of the build-texlive-2020.sh and build-asymptote.sh scripts with the -static-libstdc++ option removed. The build with the Clang compiler family then succeeded, and the binaries are available in a separate package
This is the latest stable version of the openSUSE Linux distribution. It is the free, and unsupported, companion to the commercially supported SUSE Linux system, with more than 36_700 available software packages. The build of all of TeX Live 2020 was successful.
While this work was in progress, I found that an ISO image for a pre-release of openSUSE 15.2 was available, so I built a new VM for it, and successfully installed a texlive-20200217 snapshot, including Asymptote.
This is the rolling release (development) version of the openSUSE Linux distribution. It is the free, and unsupported, companion to the commercially supported SUSE Linux system, with more than 40_000 available software packages. The build of all of TeX Live 2020 was successful for both 32-bit x86 and 64-bit x86_64 platforms.
Like CentOS 8, Oracle 8 is derived from Red Hat 8, and bugs and deficiencies of the latter affect its derivatives. I had to make the same repair to /etc/csh.cshrc, install the gcc-toolset-9 package, and build and install Clisp from source code. With the gcc version 9.1.1 compilers, I got a successful build of TeX Live 2020, including Asymptote.
Problems with the Red Hat 8 release are discussed in the section on CentOS 8. Because our Red Hat 8 system is based on a limited-time trial license, it can no longer be updated. I therefore copied the /opt/rh tree from the Oracle 8.1 system to get a compiler with a static C++ library. With the gcc version 9.1.1 compilers, I got a successful build of TeX Live 2020, including Asymptote.
Slackware Linux is one of the earliest Linux distributions, and the current stable version is 14.2, with a development channel for 15.0.
The TeX Live 2020 build on a 15.0 system from a texlive-20200220 snapshot was flawless.
Project Trident was formed in May 2018 as a split from TrueOS, which is based on the development edge of FreeBSD, but with the Lumina desktop environment instead of KDE or XFCE. In November 2019, the Trident developers announced their move from TrueOS to Void Linux, and after a release candidate that month, the first official ISO image appeared on 14 February 2020. Trident is the first Linux distribution to use ZFS as a bootable filesystem.
Void Linux uses a rolling release model, and has its own package manager, XBPS, shared by no other Linux distribution. In early 2020, its default C/C++ compiler family is gcc-9.2.0 and its Linux kernel version is 5.4.21. In addition, its default shell, /bin/sh, is a symbolic link to /bin/dash. It is in the Bourne shell family, but its executable is only about 10% the size of /bin/bash, the default shell in almost all other Linux distributions.
For most purposes, the shell difference is transparent, but I had recorded TeX Live build problems with the zziplib package in past years, and they remain in TeX Live 2020. Specifically, when the configure script for that package is run, it creates a sed script _configs.sed that uses two control characters, Ctl-A and Ctl-B (ASCII \001 and \002) in its substitution patterns. Later shell commands provide replacements for those patterns, but they are mishandled by dash, and they produce broken C code.
The fix fortunately is simple, but currently requires a manual fixup when compilation fails in the zziplib package:
% cd texlive-*/source/Work/libs/zziplib
% bash ./config.status
% cd ../..
% make world
The build then completes, and Asymptote subsequently builds without problems.
After experimenting, unsuccessfully, with changes to the zziplib configure.ac script to change the shell, I instead changed the build-texlive-2020.sh script in the Linux x86_64 block to define CONFIG_SHELL to a properly working shell, and that gave a problem-free fresh build of a texlive-20200229 snapshot.
The current main release of Ubuntu Linux is 20.04 LTS (Long Term Support): it appeared in April 2020. The Ubuntu release numbers are derived from the release date, and follow a tradition of April releases in even-numbered years getting the suffix LTS, meaning that updates are available for five years from the public release. In-between releases have much shorter support lifespans, usually just a few months.
Several other GNU/Linux distributions are based on Ubuntu Linux, including Bodhi, Budgie, elementary OS, Kubuntu, Linux Mint, Lubuntu, LXLE, Pop!_OS, Ubuntu DDE, Xubuntu, and Zorinos. They differ primarily in desktop appearance, but some of them that have reached Ubuntu base version 20.04 do not yet support the ZFS filesystem.
Ubuntu versions 19.10 (November 2019) and 20.04 (prior to April 2020) are development releases; the latter was LTS branded when it became official.
Ubuntu Linux is one of the largest, if not the largest, Linux distribution(s), with a huge package repertoire (almost 125_000 in the 19.04 release, and more than 84_000 in the 20.04 release). It is also one of the main Linux distributions that tends to offer the latest versions of software packages.
Some adventurous users, like this TeX Live developer, are willing to run prereleases of operating systems, to get a head start in software porting and testing, and some of us may also choose to file bug reports to O/S developers. However, we generally keep the user base rather limited on development systems, to avoid impacting our many other users who just want a stable computing environment that only changes at long intervals.
TeX Live 2020 builds on Ubuntu 15.10, 16.10, 17.10, 18.10, 19.10, and 20.04 x86_64 servers were uneventful, and all standard executables, including Asymptote, are available in their binary packages available from a link at the top of this Web site.
A TeX Live 2020 build attempt failed on Ubuntu 14.04 (2014-vintage) because the C++ compiler, g++-4.7.4, is too old.