Re: [lmi] Building libtiff via 'install_wx.sh'

[Vadim Zeitlin]

On Wed, 2 May 2018 21:00:20 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-05-02 16:46, Vadim Zeitlin wrote:
GC> [...]
GC> > GC> It seems curious that libtiff notices lzma but not zlib:
GC> > GC> 
GC> > GC>  Support for external codecs:
GC> > GC>   ZLIB support:                       no
GC> > GC>   ...
GC> > GC>   LZMA2 support:                      yes
GC> > GC> 
GC> > GC> but I don't actually care about that.
GC> > 
GC> >  Hmm, I don't see this here:
GC> [...]
GC> >   ZLIB support:                       yes
GC> >   Pixar log-format algorithm:         yes
GC> 
GC> I've snipped everything that matched my log. The last two lines quoted
GC> above do not: I have 'no' for both of them.

 FWIW the latter is just the consequence of the former: libtiff configure
says that "Pixar log-format algorithm" requires zlib and disables it if
zlib is not available.

GC> Both of use have 'no' on the three "JPEG" lines above. We configure wx
GC> to build both libjpeg and libz, according to this...
[...]
GC> ...but libtiff finds neither. Could that be an order dependency in the wx
GC> build system?

 No, I don't think so. wxWidgets uses built-in zlib because we explicitly
use --with-zlib=builtin for it (I forgot about this, sorry). But we don't
configure libtiff to use our zlib, even though we arguably should (and it
seems to be possible), and so if it can't find the system zlib, it doesn't
use it at all.

 In fact, not using zlib at all in libtiff is not a problem, but using a
different (system) version of zlib probably could be (although maybe it's
still fine, because we now use "wx_zlib_" prefix for all zlib symbols when
using the built-in version). I'll look into passing the appropriate options
to libtiff configure to fix this as it could become a problem for lmi if
you install the system zlib version.

 Luckily we don't have such problem with liblzma, at least, as we don't
have the built-in version of this one, so both wx and libtiff will either
use the (same) system version or won't use it at all.

GC> configure:18131: checking zlib.h usability
GC> conftest.c:125:10: fatal error: zlib.h: No such file or directory
GC>  #include <zlib.h>
GC> 
GC> configure:18131: checking zlib.h presence [similarly can't find <zlib.h>]
[...]
GC> I suppose this means that the debian MinGW-w64 port advertises libz
GC> but either doesn't provide it, or provides it as a separate package
GC> that I haven't explicitly downloaded.

 FWIW I have zlib.h in /MinGW_/i686-w64-mingw32/include, i.e. it's included
in MinGW-w64 distribution for MSW. But for Debian, it is indeed part of
libz-mingw-w64-dev (which depends on libz-mingw-w64, containing the zlib
DLL itself). So you might consider installing it, just to have one fewer
similarity between building under MSW and cross-building.

 OTOH, if you do it, then we'd end up in exactly the potentially
problematic situation described above. And so in this case I really need to
fix that or --with-zlib=builtin in install_wx.sh should be replaced with
--with-zlib=sys, so that both wxWidgets and libtiff use the same, system,
version of zlib.

 OT3H, it might be preferable to continue using wxWidgets version of zlib
rather than MinGW-w64 one because the former one should be updated faster
after any security fixes in zlib and it's easier for us to update zlib via
install_wx.sh than to wait until the new version appears in MinGW-w64 and
Debian packages. And in this case you shouldn't install the package as it
wouldn't be used anyhow.

 Sorry if all this is confusing, these transitive libraries dependencies
always end up even more complicated than they look, even when things don't
look particularly simple to begin with...

VZ