Re: [lmi] Building shared zlib

[Vadim Zeitlin]

On Tue, 29 Aug 2017 15:09:36 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-07-15 21:11, Vadim Zeitlin wrote:
GC> > On Fri, 15 Jul 2016 21:04:16 +0000 Greg Chicares <address@hidden> wrote:
GC> 
GC> [...problems building zlib for use with libxml2, which now reappear--see 
below...]
GC> 
GC> > GC> Where do we go from here?
GC> > GC>  (1) Use './configure && make' and fix up the problems manually?
GC> > GC>  (2) Try to fix the autotoolization problem?
GC> > 
GC> >  As an aside, this is how autotools undeservedly get bad reputation :-( 
The
GC> > problem is that zlib has decided not to use them, hence all this
GC> > weirdness.
GC> > 
GC> > GC>  (3) Use the msw-specific makefile provided by zlib?
GC> > GC>  (4) Just use the zlib.org msw binaries?
GC> > GC> I rate those options 2 > 4 > 1 > 3 iff (2) is easy (it's not easy for 
me),
GC> > GC> or 4 > 2 > 1 > 3 otherwise. If we're stuck with an msw-specific 
solution,
GC> > GC> then 4 >>> 3 because it's less work and less prone to error. I think 
I'll
GC> > GC> proceed with (4) provisionally; if (2) is feasible, we can switch to 
it.
GC> > 
GC> >  My personal preference is still (3) for the same reasons as stated before
GC> > (to recap: if we build some third party libraries, let's build all of 
them)
GC> > and I don't see any real drawbacks to it. (2) is easy if you agree to not
GC> > have the version information in the generated DLL, otherwise it isn't.
GC> 
GC> Before presenting the latest problems, let me ask whether there are
GC> other, better options:
GC> 
GC> (5) Use a zlib built by wx
GC> (6) Use zlib binaries provided by the MinGW-w64 maintainers
GC> (7) Drop zlib and use lzma instead

 I think that if we stay with zlib, it would really make sense to somehow
reuse the version already bundled with wxWidgets. It seems wasteful to use
2 instances of the same library in the program and, in fact, it could be
actively harmful if we end up with different versions of the same symbols
in the same binary due to this.

GC> The principal motivation, as explained here:
GC>   http://lists.nongnu.org/archive/html/lmi/2016-06/msg00046.html
GC> is to use compression as (weak) encryption, and lzma would serve
GC> that purpose just as well as zlib. Speed shouldn't be a problem:
GC>   https://tukaani.org/lzma/benchmarks.html
GC> | Decompression  In terms of speed, gzip is the winner again.
GC> | lzma comes right behind it two to three times slower than gzip.

 To be honest, I don't see any real need to bring in LZMA. It does have a
much better compression, of course, so if we cared about this, it would be
almost obviously the best choice. However we don't, whereas speed is
important and zlib is, of course, much faster: "right behind" is weird when
it's followed by "two to three times slower" and more recent benchmarks
like the one here which I just found

https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO

show that the factor is more like 4-8 for compression (but for
decompression it's indeed barely 2). Anyhow, if we really cared about
performance, we'd use LZO, LZF or Snappy, but even if we probably don't,
much, it's still at best an absence of argument in LZMA favour.

GC> Option (7) sounds most promising in light of all the difficulties
GC> we've had with zlib

 The fact that we had some build problems with zlib doesn't mean we won't
have any with lzma/xz. This is a much newer library, of course, so I'd
expect to have fewer problems, but OTOH zlib is (still) much more
widespread so I'd also expect the solutions for any problems with it to be
more readily available. There is also the fact that zlib is a very simple
library with not much code in it at all, while lzma is much less so.

 Please don't take me wrong, LZMA is a great algorithm and it's the best
one for everyday use currently, so I have only admiration for its authors,
but I just don't see any good reason to switch to it for lmi. IMHO we
should just fix whichever problem there is with zlib -- please let me know
if you'd like me to look into it.

 Regards,
VZ