[tlbuild] TeX Live 2014 build status report from Utah
Mojca Miklavec
mojca.miklavec.lists at gmail.com
Wed Apr 9 21:44:58 CEST 2014
On Wed, Apr 9, 2014 at 5:43 PM, Nelson H. F. Beebe wrote:
> Over the last month, I've created new virtual machines with these
> recent operating systems:
>
> DragonflyBSD 3.6 x86-64
> FreeBSD 10 x86-64
> NetBSD 6 x86-64
> OpenBSD 5.4 x86-64
> OpenSUSE 13 x86-64
>
> Among the now about three dozen test systems here at Utah, after 77
> separate build attempts (170 last year), I can report successful
> builds of the texlive-20140405 snapshot for these TWENTY platforms:
>
> alpha-linux-gentoo-2 x86_64-linux-arch
> i386-freebsd9 x86_64-linux-debian6
> i386-linux-fedora19 x86_64-linux-fedora19
> i386-linux-redhat5 x86_64-linux-opensuse11
> i386-linux-ubuntu12 x86_64-linux-opensuse12
> i386-solaris-11 x86_64-linux-opensuse13
> ia64-linux x86_64-linux-redhat5
> powerpc32-linux-gentoo2 x86_64-linux-redhat6
> powerpc64-linux-gentoo2 x86_64-linux-redhat7
> x86_64-dragonflybsd3.6 x86_64-linux-slackware14
>
> Among the highlights for 2014 are:
>
> * Success on GNU/Linux Alpha, which failed here last year.
>
> * Success on DragonflyBSD 3.6. Last year, on DragonflyBSD
> 3.2, the builds always hung the O/S and forced a reboot.
> This year, on 3.2, they still fail, but don't hang the
> system anymore. The DragonflyBSD master site has dropped
> all support for 3.2, and removed all binary packages for it,
> so I'm transitioning to 3.6, and 3.2 will soon be retired.
>
> * Success on both 32-bit and 64-bit GNU/Linux PowerPC;
> the last 64-bit success was for TeX Live 2009.
>
> * Success on Solaris 11 x86-64.
>
> Although I have clang versions 1.1, 3.0, 3.1, 3.2, 3.3, 3.4, and 3.5
> on various systems, compilations with clang FAIL EVERYWHERE, and
> unfortunately, it looks like configure always chooses clang/clang++
> over gcc/g++ when both are visible, so I always have to explicitly set
> CC and CXX variables.
Weird. I'm aware that ICU doesn't respect the settings and
automatically switches to clang even when gcc is explicitly set. But
other than with 3.3, clang seems to work fine for me (Mac) and Alan on
FreeBSD.
> Although many of my systems have the luajit package installed, I've
> had to build with --disable-luajittex, because builds always seem to
> fail without that action.
Can you please elaborate about this? Which machines fail and why?
> In trying to work around the build failures, on two systems, I've
> hidden the /usr/local tree in an attempt to get the build to use only
> vendor-provided libraries, header files, and utilities. On most, that
> action is impossible because it breaks a LOT of other software, and
> user logins as well.
>
> I remain frustrated by having no success whatever on
>
> * GNU/Linux on MIPS and SPARC,
Little or big endian MIPS? (In case that you have debian, what's the
output of dpkg-architecture?)
32-bit mipsel (uname returns 64) running Debian worked for me (or at
least I hope; I didn't manage to run the whole compilation in one run,
but running make again succeeded).
> * Solaris 10 SPARC, x86, and x86-64,
Solaris 10 Sparc worked for me. (TL_MAKE=gmake, but I guess you had
that setting as well.) The default compiler was too old (g++ 3.4.3 –
icu wanted to use -std=c++0x), but I switched to gcc-4.8 and that
worked (I didn't try older compilers). From what I understand
Apostolos probably got x86 working.
> * NetBSD 5 (x86) and 6 (x86-64),
> * OpenBSD 4.9 (x86), 5.1 (x86), and 5.4 (x86-64).
>
> I haven't even attempted a build on SGI IRIX MIPS, for which the last
> success was for TeX Live 2011.
>
> Nor have I attempted Mac OS X PowerPC, x86, and x86-64 builds, for
> which only Dick Koch seems to have the magic environment to succeed.
I don't have any PowerPC box, but I have no problems compiling on Mac
whatsoever. Except for an issue with cross-compiling LuaJITTeX (which
will be solved before the TL 2015 freeze ;), the last time I tried all
native and cross-compilations worked on 10.6 and 10.7.
> Some of the systems have vendor-supplied TeX binary installations,
> and some of those are from TeX Live:
>
> * Archlinux x86-64 TeX Live 2013
> * Debian 6.0.9 MIPS TeX Live 2009
> * Debian 6.0.9 x86-64 TeX Live 2009
> * DragonflyBSD 3.2 x86-64 TeX 3.1415926 (Web2C 2012) & kpathsea version 6.1.0
> * DragonflyBSD 3.6 x86-64 TeX 3.141592 (Web2C 7.5.4) & kpathsea version 3.5.4 (2004)
> * Fedora 15 x86-64 TeX 3.141592 (Web2C 7.5.6) & kpathsea version 3.5.6 (2007)
> * Fedora 19 x86 TeX Live 2013
> * FreeBSD 10 x86-64 TeX 3.1415926 (Web2C 2012) & kpathsea version 6.1.0
> * GNU/Linux Alpha TeX Live 2012
> * GNU/Linux SPARC TeX Live 2012
> * OpenBSD 5.1 x86 TeX Live 2011
> * OpenBSD 5.4 x86-64 TeX Live 2012
> * OpenSUSE 12 TeX Live 2012
> * OpenSUSE 13 TeX Live 2013
> * Red Hat 5.10 IA-64 TeX 3.141592 (Web2C 7.5.4) & kpathsea version 3.5.4 (2004)
> * Red Hat 5.10 x86 TeX 3.141592 (Web2C 7.5.4) & kpathsea version 3.5.4 (2004)
> * Red Hat 5.10 x86-64 TeX 3.141592 (Web2C 7.5.4) & kpathsea version 3.5.4 (2004)
> * Red Hat 6.5 x86-64 TeX 3.141592 (Web2C 7.5.6) & kpathsea version 3.5.6 (2007)
> * Red Hat 7.0 beta x86-64 TeX Live 2013
>
> Notice that TeX on DragonflyBSD 3.6 is 8 years older than on 3.2! At
> least my successful build on 3.6 may help to remedy that.
>
> On the failing systems, I have yet to detect any particular pattern
> that suggests a need for code changes in TeX Live; it always seems to
> be problems with compilers, or header files, or missing library
> functions.
>
> This failure on Solaris SPARC with the OpenCashew (/opt/csw/bin/) gcc
> 4.6.2 compilers, and a hidden /usr/local tree, is a sample:
>
> g++ -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
> -Wno-long-long --std=c++0x -o ../../bin/makeconv makeconv.o ucnvstat.o
> genmbcs.o gencnvex.o -L../../lib -licutu -L../../lib -licui18n
> -L../../lib -licuuc -L../../stubdata -licudata -lpthread -lm
> Undefined first referenced
> symbol in file
> __sync_sub_and_fetch_4 ../../lib/libicuuc.a(unistr.ao)
> __sync_add_and_fetch_4 ../../lib/libicuuc.a(unistr.ao)
>
> Those same __synch_*fetch_4 symbols also break the build on GNU/Linux
> SPARC with gcc 4.7.3-r1 p4.
One of the rare similar google hits was this
http://trac.wxwidgets.org/ticket/4542 (see description).
> On GNU/Linux MIPS, I get this failure:
>
> LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH
> ../bin/icupkg -tb /local/build/bare/texlive-20140405/source/Work/libs/icu/../../../libs/icu/icu-53.1/source/data/in/icudt53l.dat
> ./out/icudt53b.dat
> udata_swapDataHeader(): header size mismatch - headerSize 32768 infoSize 5120 length 1024
>
> On NetBSD 5.0 x86, I get:
>
> configure: error: There is wchar.h but the size of wchar_t is 0
>
> On NetBSD 6.0 x86-64, I get:
>
> checking for installed fontconfig headers and library... no
> configure: WARNING: Sorry, neither ApplicationServices
> framework nor fontconfig library: disabling xetex
> configure: error: terminating.
> === configuring in web2c failed
> Makefile:879: recipe for target 'recurse' failed
You really need to install fontconfig development headers. That's a
relatively common failure.
Now ... whether a "global" failure is wanted or not, I don't know.
> On OpenBSD 5.1 x86, I get in the xetex build:
>
> undefined reference to `pthread_mutex_lock'
>
> On OpenBSD 5.4 x86-64, I get
>
> checking for ft2build.h... no
> configure: error: libfreetype2 not found
>
> On that system, the available binary packages include only freetype1,
Why doesn't it find the FreeType library from TL sources?
Mojca
More information about the tlbuild
mailing list