lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Do we have zlib already?


From: Vadim Zeitlin
Subject: Re: [lmi] Do we have zlib already?
Date: Thu, 9 Jun 2016 22:45:37 +0200

On Thu, 9 Jun 2016 20:24:47 +0000 Greg Chicares <address@hidden> wrote:

GC> I just built wx, and I see:
GC> |  Which libraries should wxWidgets use?
GC> ...
GC> |    zlib               sys
GC> Does that mean we already have zlib?

 Yes, it's included in MinGW-w64 distribution and so will be detected and
used by configure unless --with-zlib=builtin (or --without-zlib, of course)
option is used.

GC> Elsewhere in my log I see:
GC> 
GC> rm -f 
/opt/lmi/wx-scratch/wxWidgets-c4d06e8.../gcc-491-97e6a75.../lib/libwxzlib-3.1-i686-w64-mingw32.a
GC> 
GC> so it looks like 'make clean' attempts to remove a 'libwxzlib'
GC> library that perhaps wx knows how to build.

 Yes, it does know how to build it, but it doesn't build it, at least for
me. I.e. there is no libwxzlib-3.1-i686-w64-mingw32.a in the "lib"
subdirectory of the wxWidgets build directory.


GC> Here's why I ask. We've been distributing product files as plain
GC> xml. They contain proprietary product data (no personal data),
GC> with an appropriate notice at the top, and they're distributed
GC> only under nondisclosure agreements. Now at least one person has
GC> suggested that it would be even better if they weren't readily
GC> human-readable, so I was thinking that compressing them with
GC> zlib might be a good idea. AFAICT, libxml2 and thus xmlwrapp use
GC> zlib transparently if it's available. And if we already have
GC> zlib (e.g. because wx knows how to build it), this might be an
GC> easy enhancement.

 Yes, I don't have any conscious experience with using libxml2 with zlib
(maybe I did use them both together, but then it happened without me
realizing it), but it's supposed to work without any extra effort on our
part, except for configuring libxml2 to use zlib. So it could be as simple
as just removing --without-zlib option from install_libxml2_libxslt.make.
Notice, however, that libxml2 would embed its own version of zlib.a from
MinGW-w64 distribution, there is no way to reuse the version already linked
into wxWidgets currently (even though we keep being asked about it) and, in
fact, we could even have a conflict between the two if we link everything
statically. OTOH as long as these two versions are completely identical,
it's probably not going to result in any problems -- but still something to
think of. Anyhow, should I try doing this?

 OTOH I also wonder if compressing files with zlib is really any different
from keeping them as plain text. I realize that you're not looking for a
three-letter-agency-proof solution, but plenty of programs have transparent
support for zlib/zip compression, so the end user might not even notice
that the file is obfuscated if it still opens as plain text when double
clicked. Perhaps it would be better to use real encryption? Even if the
encryption key could always be extracted from lmi binary, an AES-encrypted
ZIP file is not just going to open on its own when double-clicked...

 Please let me know if I should look at either (or both) compression or
(and) encryption and the priority of this compared to the other outstanding
tasks. Thanks in advance!
VZ


reply via email to

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