lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Building libtiff via 'install_wx.sh' [Was: Saving and restoring wi


From: Greg Chicares
Subject: [lmi] Building libtiff via 'install_wx.sh' [Was: Saving and restoring window geometry]
Date: Wed, 2 May 2018 21:00:20 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-05-02 16:46, Vadim Zeitlin wrote:
[...]
> GC> It seems curious that libtiff notices lzma but not zlib:
> GC> 
> GC>  Support for external codecs:
> GC>   ZLIB support:                       no
> GC>   ...
> GC>   LZMA2 support:                      yes
> GC> 
> GC> but I don't actually care about that.
> 
>  Hmm, I don't see this here:
[...]
>   ZLIB support:                       yes
>   Pixar log-format algorithm:         yes

I've snipped everything that matched my log. The last two lines quoted
above do not: I have 'no' for both of them.

>   JPEG support:                       no
>   Old JPEG support:                   no
>   JPEG 8/12 bit dual mode:            no

Both of use have 'no' on the three "JPEG" lines above. We configure wx
to build both libjpeg and libz, according to this...

  Which libraries should wxWidgets use?
                                       STL                yes
                                       jpeg               builtin
                                       png                builtin
                                       regex              builtin
                                       tiff               builtin
                                       lzma               yes
                                       zlib               builtin
                                       expat              builtin
                                       libmspack          no
                                       sdl                no


...but libtiff finds neither. Could that be an order dependency in the wx
build system?

>  As you say, this isn't really important, but if you're curious, you could
> have a look at config.log created by libtiff configure and search it to
> find out why did zlib test fail.

Below are the relevant parts of
  
/srv/chroot/lmi-buster/opt/lmi/vcs/wxWidgets/lmi-gcc-7.3-win32/src/tiff/config.log

...Invocation command line was
  $ ../../../src/tiff/configure --disable-option-checking ...
 --enable-vendor=gcc-7.3-win32-e38866d3a603f600f87016458260f73593627348 ...
 --with-zlib=builtin ...

configure:3927: i686-w64-mingw32-gcc -v >&5
Using built-in specs.
Configured with: ... --with-system-zlib

[so MinGW-w64 gcc says it provides zlib]

configure:18131: checking zlib.h usability
conftest.c:125:10: fatal error: zlib.h: No such file or directory
 #include <zlib.h>

configure:18131: checking zlib.h presence [similarly can't find <zlib.h>]

configure:23028: WARNING: unrecognized options: --disable-apple_ieee, ... 
--with-zlib
[but we know that not all libraries recognize all wx options]

I suppose this means that the debian MinGW-w64 port advertises libz
but either doesn't provide it, or provides it as a separate package
that I haven't explicitly downloaded.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]