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

[Vladimir Volovich]

"KB" == Karl Berry writes:

 KB> Peter doesn't mention i386-linux.  As far as I can tell the xetex
 KB> binary I made for i386-linux (on Debian Sarge) in 2008 does have
 KB> explicit dependencies on

 >	linux-gate.so.1 =>  (0xb7f99000)
 >	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0091e000)
 >	libm.so.6 => /lib/libm.so.6 (0x005d9000)
 >	libc.so.6 => /lib/libc.so.6 (0x00493000)
 >	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00864000)
 >	libexpat.so.0 => /lib/libexpat.so.0 (0x00841000)
 >	/lib/ld-linux.so.2 (0x00470000)

Master/bin/i386-linux/xetex which is currently in the TL repository
(from TL2008) has only indirect dependency on libfreetype, libz and libexpat:

$ strings -a xetex | egrep 'lib(fontconfig|freetype|z|expat)'
libfontconfig.so.1

they are, of course, reported by "ldd", but only because they are
required by libfontconfig.so.1, but not directly by xetex.

 KB> (But not libz, which was statically linked.  From what I gather of
 KB> previous discussion, it's not easy to change libz back to static in
 KB> xetex under the new regime.)

 KB>     so i'm trying to avoid unnecessary direct dependencies on
 KB> system libfreetype and libz.

 KB> If we can make the dependencies indirect, surely that is all to the
 KB> good.  But I think the evidence is that it is not crucial if we
 KB> don't.  At least I never saw reams of (or any) complaints from
 KB> users about how their xetex wouldn't run.

well, see this thread: http://www.tug.org/pipermail/tex-live/2007-May/013555.html

(and, for solaris, since /opt/csw is not a very standard location which
is guaranteed to contain libfreetype, libz, etc, it is better to avoid
unnecessary dependency on those libraries in /opt/csw;

and the way xetex is built on solaris, libfontconfig.so.1 will be picked
up from a system location such as /usr/lib if it is not found in /opt/csw/lib)

Best,
v.