[tex-k] teckit/svn -- first comments
peb at mppmu.mpg.de
Mon Apr 7 15:20:37 CEST 2008
On Fri, 4 Apr 2008, Jonathan Kew wrote:
> The part that I can't seem to get right is how to handle zlib neatly. There
> are several scenarios that should ideally all be considered:
> - no zlib library is available, so the teckit build should use its own local
> - zlib is available in the system, so the teckit build should use it by
> default (unless --without-system-zlib is specified)
> - the standard teckit build should result in both shared and static libs,
> with the executables using the shared libs
> Then, when we drop the teckit sources into texlive, the defaults should be
> changed such that --without-system-zlib is the default, and an installed
> (shared) lib is used only if explicitly requested.
It seems at the moment just dropping the teckit sources into texlive does
not work (and maybe never will[*]). That's what I meant by extracting the
zlib-related part of configure.ac into a separate file (e.g. zlib.m4) with
one version for a standalone build and another version for a texlive build
-- whereas the rest of configure.ac and the Makefile.am's are the identical.
[*] Unless you are willing to put code into the standalone configure.ac that
detects being part of a texlive build. Sort of ugly.
> I can put @LDZLIB@ into the _LDADD variables for the teckit executables,
> that's fine.
> But what about the link commands for the libraries? AFAICT, to link shared
> teckit libraries using the system's zlib, it is necessary to include -lz (via
> @LDZLIB@) in the library _LDFLAGS, otherwise they fail to link (undefined
> symbols). But if we do this, the static build will have libz.a there, and is
> what caused the problem that Vladimir reported.
you are absolutely right. The whole problem comes from trying to have the
libtool library libTECkit.la depend on a possibly uninstalled non-libtool
The above is, however, not exactly right. The problem comes from having both
libz.a and -lz on the libtool command line, -lz alone is OK (but see below).
I agree, we might eventually want to convert the bundled zlib into a libtool
library. Fairly easy to do, but certainly not for TL/2008.
BTW: The same problem occurs with libfreetype.la, but there they use
libtool --mode=link -o libfreetype.la ... -lz
without adding ../zlib/libz.a! Thus for libfreetype.so they probably pick up
the installed shared libz.so.
Maybe one can't build libTECkit.so or libfreetype.so without having libz.so
(possibly via libz.la and/or uninstalled) -- but so what.
Jonathan and Karl,
there is, however, a related problem due to the cxx-runtime-hack. There
xetex and pdftex are linked with "CXX", not with "libtool --mode=link CXX".
The reason is that libtool effectively ignores the special flags
"-nodefaultlibs -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic".
With a more recent libtool (1.5.24 or later), one could, however, use
"libtool --mode=link CXX -static-libtool-libs". That would prefer static
libraries over shared ones (applies to uninstalled as well as installed
libtool libraries). Again that is certainly not for TL/2008.
For TL that would use mostly static libs. For distros one would use
--without-cxx-runtime-hack and for most libs --with-system-LIB resulting in
the use of mostly shared libs.
More information about the tex-k