Re: [lmi] Testing build with native MinGW 4.9.1

[Greg Chicares]

On 2016-01-21 20:09, Vadim Zeitlin wrote:
> 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> > 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.

Okay, let's try that.

> 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

I have a dream: I use GNU/Linux exclusively for writing code and testing it;
others who run msw exclusively compile the same code and distribute it to
end users; and both versions behave identically, so I don't ever have to
boot an msw machine except to verify that the behavior is identical or to
investigate some OS-specific quirk. To bridge the OS gap, I need to be able
to cross compile.

I don't know whether numeric results can be identical with two different
C runtimes. Maybe it's not an achievable dream. But in order to try, I need
to avoid gratuitous differences, such as different versions of libraries.

There seem to be two ways I can use the same version of library X for
both x86_64-linux-gnu and i686-w64-mingw32:
 (1) choose the version provided with my OS, and use that for both; or
 (2) choose any version we like, perhaps the latest, and build it from
     upstream (not debian) sources for both--which means keeping the
     x86_64-linux-gnu builds outside the normal FHS locations.
I was just thinking that (1) would be easier, and perhaps it is at first;
but (2) shouldn't be much more work, and seems better for the long term.
What do you think?

> 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).

With method (2) above, we could use libxml2-2.9.3 (2015-11-20). It doesn't
matter whether that version is compatible with any OS release because we'd
be building and maintaining it separately. That means we won't get debian
(easily applied) security patches, but we'll get xmlsoft's (which we'll
have to apply ourselves). I don't suppose this extends my machine's attack
surface materially if I have local builds in (say) /opt, sequestered from
everything else.

> 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.

This sounds compatible with method (2) above.

> 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.

Volatile writes can't be optimized away by the *compiler*, but my hope is
that the same principle extends to the linker; I guess that hope is vain.