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

Vladimir Volovich vvv at vsu.ru
Fri May 15 18:33:58 CEST 2009


"PB" == Peter Breitenlohner writes:

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

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

What i want to achieve is to have a direct (explicit) dependency (for xetex and
xdvipdfmx) only on libfontconfig.so, but to have the rest of
dependencies (on libfreetype, libiconv, libz, libexpat) as indirect
dependencies "inherited" from libfontconfig.so.

Let me show what i mean by a direct (explicit) dependency.

1) for the binary which depends explicitly only on libfontconfig:
   when i run "ldd -v xetex" on solaris, i see:

$ strings -a xetex | egrep 'libfontconfig|libfreetype|libz'
libfontconfig.so.1

$ ldd -v xetex

   find object=libfontconfig.so.1; required by xetex
        libfontconfig.so.1 =>    /opt/csw/lib/libfontconfig.so.1

   find object=libm.so.1; required by xetex
        libm.so.1 =>     /lib/libm.so.1
[...]
   find object=libiconv.so.2; required by /opt/csw/lib/libfontconfig.so.1
        libiconv.so.2 =>         /opt/csw/lib/sparcv8/libiconv.so.2

   find object=libfreetype.so.6; required by /opt/csw/lib/libfontconfig.so.1
        libfreetype.so.6 =>      /opt/csw/lib/sparcv8/libfreetype.so.6

   find object=libz.so; required by /opt/csw/lib/libfontconfig.so.1
        libz.so =>       /opt/csw/lib/sparcv8plus+vis/libz.so

   find object=libexpat.so.0; required by /opt/csw/lib/libfontconfig.so.1
        libexpat.so.0 =>         /opt/csw/lib/sparcv8/libexpat.so.0

2) now compare this with the binary which has more explicit dependencies:

$ strings -a xetex | egrep 'libfontconfig|libfreetype|libz'
libfontconfig.so.1
libfreetype.so.6
libz.so

$ ldd -v xetex

   find object=libfontconfig.so.1; required by xetex
        libfontconfig.so.1 =>    /opt/csw/lib/libfontconfig.so.1

   find object=libfreetype.so.6; required by xetex
        libfreetype.so.6 =>      /opt/csw/lib/libfreetype.so.6

   find object=libz.so; required by xetex
        libz.so =>       /opt/csw/lib/libz.so

   find object=libm.so.1; required by xetex
        libm.so.1 =>     /lib/libm.so.1
[...]
   find object=libiconv.so.2; required by /opt/csw/lib/libfontconfig.so.1
        libiconv.so.2 =>         /opt/csw/lib/sparcv8/libiconv.so.2

   find object=libfreetype.so.6; required by /opt/csw/lib/libfontconfig.so.1

   find object=libz.so; required by /opt/csw/lib/libfontconfig.so.1

   find object=libexpat.so.0; required by /opt/csw/lib/libfontconfig.so.1
        libexpat.so.0 =>         /opt/csw/lib/sparcv8/libexpat.so.0

as you see, in the latter case, the xetex binary contains a direct
linkage with system libraries libfreetype.so.6 and libz.so (in addition
to libfontconfig.so.1), because the it was linked with them.

in the first case, xetex only depends on libfontconfig.so.1, and the
rest is taken from indirect dependencies (because libfontconfig.so.1 on
my implementation happens to link with those other libraries).

it is more portable to limit the direct dependency only to
libfontconfig.so.1, and avoid unnecessary dependency on libfreetype.so.6
and libz.so (which may not be found, depending on the way libfontconfig
will be compiled on the user's system).

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

i got an impression that it is the -L/opt/csw/lib which affects
libtool's visibility of other libraries. i.e. if one uses

cc -o xetex ... \
  -L/opt/csw/lib -lfontconfig \
  -L/opt/home/vvv/src/texlive/source/Work/libs/freetype2 -lfreetype2 \
  /opt/home/vvv/src/texlive/source/Work/libs/zlib/libz.a ...

then -L/opt/csw/lib will take precedence over
-L/opt/home/vvv/src/texlive/source/Work/libs/freetype2
and libtool will link with -lfreetype2 found in /opt/csw/lib (which is
the case) instead of /opt/home/vvv/src/texlive/source/Work/libs/freetype2/libfreetype.a

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

as far as i see, a fix for xetex is simple one, something like this:

========================
--- texk/web2c/xetexdir/am/xetex.am	(revision 13098)
+++ texk/web2c/xetexdir/am/xetex.am	(working copy)
@@ -36,7 +36,7 @@
 
 xetex_cppflags += -DXETEX_OTHER
 xetex_cppflags += $(XPDF_INCLUDES) $(LIBPNG_INCLUDES) $(FONTCONFIG_INCLUDES)
-xetex_ldadd += $(XPDF_LIBS) $(LIBPNG_LIBS) $(FONTCONFIG_LIBS)
+xetex_ldadd += $(XPDF_LIBS) $(LIBPNG_LIBS)
 xetex_dependencies += $(XPDF_DEPEND) $(LIBPNG_DEPEND)
 
 endif !XETEX_MACOSX
@@ -53,6 +53,12 @@
 xetex_ldadd += $(FREETYPE2_LIBS) $(ZLIB_LIBS)
 xetex_dependencies += $(FREETYPE2_DEPEND) $(ZLIB_DEPEND)
 
+if !XETEX_MACOSX
+
+xetex_ldadd += $(FONTCONFIG_LIBS)
+
+endif !XETEX_MACOSX
+
 xetex_CPPFLAGS = $(xetex_cppflags)
 
 ## With --enable-ipc, XeTeX may need to link with -lsocket.
========================

at least it should not do any harm, right? and it does prevent the
direct dependency on system libfreetype.so.6 and libz.so here.

as for xdvipdfmx, the way -L/opt/csb/lib is passed to Makefile is a bit
trickier and i did not look in detail where it is done. but the trick is
also to move it, together with -lfontconfig, closer to the end of command.

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

these are indirect dependencies, as explained above. e.g. you should not be
seeing libexpat inside the xetex binary. it is induced by fontconfig.

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

Best,
v.


More information about the tlbuild mailing list