[tex-k] teckit/svn -- first comments

[Peter Breitenlohner]

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 
> copy
>
> - 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.

Hi Jonathan,

you are absolutely right. The whole problem comes from trying to have the
libtool library libTECkit.la depend on a possibly uninstalled non-libtool
library libz.a.

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.

Peter