Re: [lmi] Testing build with native MinGW 4.9.1

[Vadim Zeitlin]

On Thu, 21 Jan 2016 00:20:54 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-20 21:16, Vadim Zeitlin wrote:
...
GC> > So this explains the problem: MinGW-w64 4.9.1 comes with zlib 1.2.8 and
GC> > without the fix above, libxml2 can't work with it.
GC> 
GC> Hmmm. Our old mingw.org toolchain had no zlib:
GC>   /opt/lmi/MinGW-20090203-mingw-org[0]$ls **/zlib*
GC>   zsh: no matches found: **/zlib*
GC>   /opt/lmi/MinGW-20090203-mingw-org[1]$ls **/libz*
GC>   zsh: no matches found: **/libz*
GC> but the new MinGW-w64 toolchain provides it (who ordered that?):
GC>   /MinGW_[0]$ls **/libz*
GC>   i686-w64-mingw32/lib/libz.a
GC> (I wonder why we never needed '--without-zlib' before, even though
GC> we were building without zlib. I guess this option means "exclude
GC> zlib even if it's detected (and if it's not detected, it'll be
GC> excluded silently even without this option)".

 Yes, exactly, sorry for not explicitly mentioning this, but this is the
way configure options always work: by default, the dependency will be used
if found but normally the main project can still be built without it
(otherwise the dependency wouldn't have been optional!), so specifying
--without-foo doesn't change anything if foo can't be found anyhow.

GC> There's nothing wrong with using old libraries for more than a
GC> decade--RHEL LTS does it:

 As someone who regularly has to ship code to customers using ancient RHEL,
I can say that there could well be nothing wrong with it, but it's very
painful.

GC> Now that we have zlib, can any other library (wx, for instance) make
GC> good use of it?

 I didn't think to check it, but normally wxWidgets should already be using
it by default. And, after checking config.log, I can confirm that it does.

GC> Or, in a world where bzip2 is obsolescent and md5sums are obsolete,
GC> does it make any sense to use zlib? It's just LZ77 AFAICT,
GC> contemporaneous with "Muskrat Love", and do compression algorithms age
GC> better than pop music?

 Almost certainly worse ("classic compression algorithm" doesn't sound very
good), but even if there are better algorithms now, the difference between
them and zlib is still much smaller than difference between zlib and
uncompressed text files, so it could still be worth using. Also, it's used
by libpng, so it's not like we could avoid having it anyhow.

GC> > FWIW I also checked that the latest libxml2 can be built without
GC> > neither --without-threads nor --without-zlib and still works
GC> > correctly.
GC> 
GC> Well...since you've already done the work to verify that...and since
GC> we're already rebuilding libxml2 and libxslt and therefore need to
GC> test them both anyway...does it make sense to upgrade both those
GC> libraries now?

 Yes, I think it does as it should be simple to do and would free us from
the need to apply extra patches to them.

GC> And which versions would we use, given that I'd like
GC> to cross-compile from debian-7?

 I'm not sure what is the relationship between the version and
cross-compiling (more about this below).

GC> https://packages.debian.org/wheezy/libxml2
GC> | libxml2 (2.8.0+dfsg1-7+wheezy5) [security]

 Also, Debian is not known for having the most up to date packages but I
think it's unfair to use the Wheezy version when Jessie is the new stable
since more than a year already. And Jessie has a somewhat more recent 2.9.1
(Apr 2013).

GC> http://www.xmlsoft.org/news.html
GC> | v2.9.3: Nov 20 2015 [latest]
GC> | 2.8.0: May 23 2012
GC> |   Features: add lzma compression support (Anders F Bjorklund)
GC>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GC>     (Does that answer my zlib question above?)

 It's not like we use any compression with libxml2 anyhow, so it doesn't
change much for us.

GC> OTOH, end users install lmi in its own isolated directory, and lmi
GC> code isn't network-aware, so do all those CVEs matter a whole lot?
GC> Would any malefactor ever even think of mounting a "billion laughs
GC> attack" on lmi? If we're already updating from 2006 to 2012, is
GC> there a compelling reason to go all the way to 2015 even though it
GC> makes cross-compiling from debian-7 more difficult?

 It doesn't actually make cross-compiling more difficult unless you want to
cross-compile from Debian package sources which doesn't seem to have any
advantages. It's not like Debian provides, or is ever going to provide, any
MSW binaries. So we will need to get the sources and build it ourselves
anyhow and from this point of view it seems that we should use the latest
version.


GC> >  The only still remaining question is why did I need to apply the patch to
GC> > ensure that the alert functions are linked in with the Debian
GC> > cross-compiler but not the native compiler. I'm not sure if it's worth
GC> > debugging this further, however, as it's clearly an
GC> > implementation-dependent optimization anyhow. It would be better to just
GC> > apply the patch to make sure the problem can never arise rather than
GC> > hoping that it doesn't.
GC> 
GC> So...when cross compiling from debian, you received a build-time error?

 No, sorry, it's the same error as before, i.e. there are no errors during
the build, but the object files containing the wx implementations of the
alert functions just get discarded at the link stage and the resulting
binary exits with "not all alert functions pointers were set" error during
run-time.

GC> I've always insisted that the "volatile bool ensure_setup" technique is
GC> guaranteed to work by the C++ standard;

 I'm not totally sure about this, but I don't think so. In any case, even
if you're right, pragmatically speaking, this hardly makes any difference.

GC> Okay...so at first we didn't need it, then we needed it in some cases
GC> but not others because of one particular linker, and now we need it in
GC> one more case because of one more linker,

 BTW, the reason we didn't need it for MSVC is that we included
alert_wx.cpp in the main lmi_wx project instead of including it in a
library. I don't remember why had it been done like this any more, but I
suspect it was already to work around this problem.

GC> so...should we just take care
GC> of all cases presumptively now, and never revisit this again? I guess
GC> our universe of consideration is the cross product of
GC>   {file_command,progress_meter,system_command,pdf-thing | 
alert,mc_enum_types_aux}
GC>     (components listed left of '|' already handled)
GC> and
GC>   {wx, cgi, cli}
GC>     (only wx handled; the others might use libraries someday)
GC> so should we now add 'mc_enum_types_aux' as well as 'alert', and write
GC> LMI_FORCE_LINKING_EX_SITU in 'main_c[gl]i.cpp' too? It looks so simple
GC> that I think I'll just do it.

 I can guarantee that it won't do any harm, but it doesn't seem to be
needed for mc_enum_types_aux because it contains other functions that are
explicitly used from other files (e.g. effective_dbopt_7702()), and so we
can be sure that it will be never optimized away.

 Regards,
VZ