Re: [lmi] Testing build with native MinGW 4.9.1

[Vadim Zeitlin]

On Fri, 22 Jan 2016 06:19:45 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-21 20:09, Vadim Zeitlin wrote:
GC> > 
GC> >  I'm not sure what is the relationship between the version and
GC> > cross-compiling
GC> 
GC> I have a dream: I use GNU/Linux exclusively for writing code and testing it;
GC> others who run msw exclusively compile the same code and distribute it to
GC> end users; and both versions behave identically, so I don't ever have to
GC> boot an msw machine except to verify that the behavior is identical or to
GC> investigate some OS-specific quirk. To bridge the OS gap, I need to be able
GC> to cross compile.

 Unfortunately I don't think this dream is very realistic because there
will inevitably be some platform-specific quirks. We can try to minimize
them, but the behaviour of MSW and GTK GUIs are just never going to be the
same and, compared with this major difference, the differences between
libxml2 2.9.1 and 2.9.5 or whatever is really negligible.

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

 In principle, I understand what you're saying, but in practice I think
this will be the last of the problems with your dream.

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

 I agree that (1) is easier than (2), but I think the easiest of all is

(3) use the OS version for native Debian builds and the latest version when
    building from source.

This does mean that we're going to use different versions for Debian and
MSW builds, but, again, I don't think it's a huge problem considering all
the other differences between them.

 If you still want to use exactly the same versions of all the libraries,
then (1) seems easier at a first glance, but considering that Debian
packages quite often apply Debian-specific patches to them, I think (2)
might be a better choice just because we can be more or less sure that we
can always compile both versions from the upstream sources while Debian
patches could, in principle, break MSW cross-compilation (I don't know how
likely is that because I've never tried to cross-compile from Debian
package sources).

GC> > GC> I've always insisted that the "volatile bool ensure_setup" technique 
is
GC> > GC> guaranteed to work by the C++ standard;
GC> > 
GC> >  I'm not totally sure about this, but I don't think so.
GC> 
GC> Volatile writes can't be optimized away by the compiler, but my hope is
GC> that the same principle extends to the linker; I guess that hope is vain.

 Yes, this is why I don't think this is guaranteed to work. AFAIK
"volatile" is only taken into effect when generating the code using the
variable (or, to be more formal, affects the behaviour of this code when it
runs), but I'm not sure if it has any bearing on whether this code is
executed at all in the first place.

VZ