[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