[tlbuild] xetex and xdvipdfmx: explicit dependency on external libfreetype and libz

[Peter Breitenlohner]

On Fri, 15 May 2009, Vladimir Volovich wrote:

> Hi Jonathan and Peter,
>
> in TL2009, xetex and xdvipdfmx appear to have explicit dependencies on
> external libfreetype.so.6 and libz.so.

Hi Vladimir,

I assume your concern is that xetex and xdvipdfmx explicitly depend on
libfreetype.so, libexpat.so, and libz.so (each probably with the major
version number encoded into libfontconfig.so on the build system).

Putting the flags for libfontconfig at the end may work in your case but is
no general receipe.

Consider these alternative situations:

(1a) The system has a shared (and possibly static) fontconfig library
(1b) The system hos only only a static fontconfig library (unlikely but
      possible).

(2a) There is a libfontconfig.la file
(2b) There is no libfontconfig.la file (some distros in their `superior
      wisdom' decide against installing .la files).

(3a) The system uses ELF shared libraries (or equivalent), that have all
      their dependencies encoded into the .so (or .dylib or ...) file.
(3b) Dependencies are not encoded into the shared libraries.

Which are your alternatives? I'd guess 1a+2b+3a.

Now imagine these scenarios (always with -lfontconfig late in the libtool
command line):

(I) 1b+2b: will fail  with unresolved symbols

(II) 1b+2a: will probably pull in the system libfreetype.a and libz.a, may
succeed or may file with duplicate symbols

(III) 1a+2b+3a: may give your desired result

(IV) 1a+2b+3b: will probably fail with unresolved symbols

(V) 1a+2a: Libtool will gratuitously add libfreetype, libexpat and libz to
the commandline passed on to g++ or gcc

An example: I usually build with several system libraries, but when I
do 'make distcheck' this is done without any system libraries other than
fontconfig.

Here is what I see in the log file (with XXX the absolute path of a
temporary source tree:

/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 \
 	-o xdvipdfmx agl.o agl_standard.o bmpimage.o cff.o \
 	[many more objects] \
 	unicode.o vf.o xbb.o \
 	XXX/_build/texk/kpathsea/libkpathsea.la \
 	-LXXX/_build/libs/freetype2 -lfreetype \
 	XXX/_build/libs/libpng/libpng.a \
 	XXX/_build/libs/zlib/libz.a \
 	-lfontconfig -lm 
libtool: link: gcc -g -O2 \
 	-o xdvipdfmx agl.o agl_standard.o bmpimage.o cff.o \
 	[many more objects] \
 	XXX/_build/texk/kpathsea/.libs/libkpathsea.a \
 	-LXXX/_build/libs/freetype2 XXX/_build/libs/freetype2/libfreetype.a \
 	XXX/_build/libs/libpng/libpng.a \
 	XXX/_build/libs/zlib/libz.a \
 	/usr/lib/libfontconfig.so /usr/lib/libfreetype.so -lz /usr/lib/libexpat.so -lm

================================

I agree that the current situation is far from ideal, but all this will need
further consideration and maybe some experimentation with a tiny test program.

BTW: in the TL2008 build (Master/bin/*/{xetex,xdvipdfmx}) the xetex for
i386-openbsd and the xdvipdfmx for i386-openbsd, i386-freebsd,
amd64-freebsd, x86_+64-linux, and powerpc-linux all depend os system
freetype, expat and z libraries.

Regards
Peter