[tlbuild] TeX Live 2013 build status at Utah
Nelson H. F. Beebe
beebe at math.utah.edu
Tue May 28 16:39:26 CEST 2013
I've not had much time this year to work on TeX Live builds. Over the
weekend, I made an intensive effort to try them on almost all of my
30+ flavors of Unix, skipping only one machine that is down, our old
SGI MIPS IRIX, and Minix (which, I suspect, has never had TeX)
Here is a summary of 18 successes, using the bin subdirectory names:
alpha-linux i386-solaris-11 x86_64-linux-archlinux
i386-freebsd9.1 ia64-linux x86_64-linux-debian-6
i386-linux powerpc-linux x86_64-linux-fedora-15
i386-linux-fedora-17 ppc64-linux x86_64-linux-osuse-11
i386-linux-ubuntu-12 sparc-linux x86_64-linux-osuse-12
i386-openbsd4.9 x86_64-linux x86_64-linux-rhel-6
i386-linux and x86_64-linux are Red Hat Enterprise Linux (RHEL) 5.9
builds.
The GNU/Linux ones correspond to all of the CPU architectures that we
have that O/S on here (Alpha, PowerPC-32, PowerPC-64, SPARC, x86,
x86_64), so I conclude that TeX Live 2013 builds fine for GNU/Linux.
I have a GNU/Linux slackware VM as well, but it is currently down with
a network issue after a kernel update; when I get it up, I'll try
builds there too.
However, of the above systems, only alpha-linux and x86_64-linux have
asy.
Here are the ones that have xindy:
alpha-linux x86_64-linux-debian-6
i386-linux-fedora-17 x86_64-linux-fedora-15
i386-linux-ubuntu-12 x86_64-linux-osuse-11
i386-linux x86_64-linux-osuse-12
powerpc-linux x86_64-linux-rhel-6
x86_64-linux-archlinux x86_64-linux
Those that are missing xindy are because of the inability of clisp
either to compile, or to pass its validation suite, on some platforms.
Notably absent from the above lists are Solaris 10 (SPARC, x86,
x86_64) [formerly our major platform for thousands of users], and all
but two of the BSD variants.
Solaris 10 has been included on all previous TeX Live releases, and
goes back more than a decade. Solaris 11 has certainly not replaced
it on our campus, and will not because of Oracle licensing costs. I
suspect many other Solaris sites have made similar cost-based choices.
Over the weekend, I rebuilt and reinstalled libiconv-1.14 with both
shared and static libraries on all systems, because the ongoing
problem with TeX Live builds has been the dependency of xdvi-xaw and
xindy on /usr/local/lib/libiconv.so.
By patching Makefiles to replace -liconv with ${libdir}/libiconv.a, I
can eliminate the only references to our /usr/local tree. However,
because the Build script insists on doing the rough equivalent of
"configure && make", there is no opportunity to apply the Makefile
patches between those two steps.
I strongly recommend for next year that Build be revised to something
like "configure && postconfigure && make", where postconfigure
defaults to true, but can be overridden by environment variables.
Most packages that use -liconv can be configured without it, but not
xdvik: it ignores any --without-iconv or -with-iconv=no options.
Examination of its configure script shows that is can be built with
--with-recode instead, to use librecode. I tried that, but that too
failed. librecode has not changed in a dozen years, and I've given up
on trying to build it on our systems, after several failed, or went
into infinite loops. I did, however, install binary packages for it
on several of our GNU/Linux systems.
Here is a brief summary of the show stoppers:
------------------------------------------------------------------------
Dragonfly BSD 3.2 x86_64
The binary package system for this BSD variant has 10,126 available
packages, so a huge amount of software, including TeX Live 2012, is
available for it.
With TeX Live 2013, all but the last attempt hung the virtual machine,
and required reboots.
Before the most recent reboot, I increased the VM DRAM size from 1GB
to 2GB. On the last TeX Live build attempt, I caught it in time and
killed the build before it consumed all process resources.
What happens is this:
make[3]: Entering directory `/local/build/bare/texlive-20130524/source/Work/libs/freetype'
...
checking whether to build static libraries... yes
checking for fort77 option to produce PIC... -fPIC
checking if fort77 PIC flag -fPIC works...
[no more output]
With the top utility, I found that more than 700 perl processes were
running, and the number was rapidly increasing.
This is a relatively new VM, and its perl version is the same as that
on most of our other systems. A brief grep of freetype configure
files does not turn up references to perl.
More debugging is clearly required here to find out why perl is
reinvoking itself ad infinitum.
------------------------------------------------------------------------
Mac OS X 10.5.8 PowerPC and Mac OS X 10.7.5 x86:
ld warning: in ./.libs/libkpathsea.a, file is not of required architecture
Undefined symbols:
"_kpathsea_var_expand", referenced from:
_main in kpsewhich.o
... many more ..
I have NEVER got any TeX Live version from this year, or any previous
year, to build on Mac OS X on either PowerPC or x86.
------------------------------------------------------------------------
MirBSD 10 x86:
Native g++ (3.4.6) cannot compile graphite2-1.2.1; no newer version
of a C++ compiler is available on this platform.
------------------------------------------------------------------------
NetBSD 5.1 x86:
make[4]: Entering directory `/local/build/bare/texlive-20130524/source/Work/libs/icu'
...
configure: error: There is wchar.h but the size of wchar_t is 0
wchar_t on this system has broken builds of other packages that try to
use it.
------------------------------------------------------------------------
OpenBSD 5.1 x86:
Native g++ (4.2.1) fails to compile icu-51.1, and no newer version
of a C++ compiler is available.
------------------------------------------------------------------------
Solaris 10 x86_64 (32-bit build):
Native g++ (3.4.3) fails to compile cairo-1.12.8, raising an internal
compiler error at expmed.c:2656.
------------------------------------------------------------------------
Solaris 10 SPARC (32-bit build):
Native g++ (4.1.3) fails to compile cairo-1.12.8, raising an internal
compiler error at expmed.c:2656.
------------------------------------------------------------------------
It seems likely that having newer gcc-4.x compiler families installed
might remove the failures. To that end, I have 2442 logs of build
attempts for gcc-4.x releases on all of our systems made over several
years. Sadly, the gcc-4.x family portability is poor compared to that
of the gcc-2.x and gcc-3.x families, and successful builds of gcc-4.x
snapshots are rare outside the GNU/Linux x86_64 and x86 platforms.
llvm + clang + clang++ might offer an alternative compiler family, but
those compilers are written in C++, and will compile only with fairly
recent g++ releases, so that avenue is blocked on many systems. It
MIGHT be possible to do a cross-compile build of llvm from some other
system, but the system is so complex, with millions of lines of code,
that I would not expect success.
Today, I'm going to try Solaris 10 builds with newer compilers on
SPARC and x86; almost no gcc-4.x releases will build successfully on
any flavor of Solaris 10.
It seems that cairo is new this year: luatex and mpost depend on it.
It would be a good idea to have a top-level configure --without-cairo
option to revert to something close to last year's code not requiring
cairo.
Here are some important lessons for future software developers:
(1) Stick to ISO Standard C (preferably 1989 level, c89); it is highly
unlikely that you need to use any of the c99 extensions, and you
certainly do not need any gcc-specific extensions.
(2) Avoid programming in C++ entirely!
(3) Never adopt a dependent package (like icu or cairo) until you have
determined that it is universally portable to all platforms, and
has been so for several versions.
(4) Build and validate your code on dozens of platforms before turning
it loose on the public (the gcc people really need to practice
that rule!).
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
More information about the tlbuild
mailing list