Re: [lmi] Testing build with native MinGW 4.9.1

[Vadim Zeitlin]

On Wed, 20 Jan 2016 18:00:44 +0000 Greg Chicares <address@hidden> wrote:

GC> >  After this, the rest went on without any problems but running lmi I
GC> > immediately get a segmentation fault. I thought it was due to the problem
GC> > with the alert function pointers also mentioned in my message above, but,
GC> > strangely, enough this problem doesn't seem to arise. OTOH libxml2 seems
GC> > not to work at all when compiled with this compiler in the official way
GC> > (i.e. using install_libxml2_libxslt.make) because the segfault happens
GC> > inside its internal __xmlParserInputBufferCreateFilename() function and I
GC> > can reproduce it easily outside of lmi by just using the testReader 
program
GC> > included in libxml2 itself. I have no idea what's going on here, debugging
GC> > it shows that zlib gzopen() function returns something that doesn't look
GC> > valid at all and it's dereferencing this something later in the code that
GC> > results in a crash. This is definitely not normal and I don't understand
GC> > it, but for now I've just disabled compressed files support in libxml2 
(see
GC> > another attached patch, which depends on --without-threads solving the
GC> > compilation problem) and then everything seems to work.
GC> 
GC> Wow. I'm very grateful that you found that problem and solved it.

 I was so worried by not understanding what it was due to, that I spent
even more time and I think I finally did find the reason: in some
prehistoric times (definitely before zlib 1.2.3 released 10.5 years ago and
maybe for quite some time longer), z_stream type used by zlib IO functions
and gzFile type returned by gzopen() was one and the same or, at least,
interchangeable and libxml2 abused this and used the latter as the former.
This doesn't work at all in any more or less recent zlib versions (and this
is what I saw under debugger and which made me doubt the integrity of my
build) because the types are completely different and it was fixed in
libxml2 itself 6 years ago, see

https://github.com/GNOME/libxml2/commit/a7e79f28689c574e0bbef17f4cb3da00249181ff

So this explains the problem: MinGW-w64 4.9.1 comes with zlib 1.2.8 and
without the fix above, libxml2 can't work with it. FWIW I also checked that
the latest libxml2 can be built without neither --without-threads nor
--without-zlib and still works correctly.

GC> >  To summarize, globally things look good but they didn't work out of the
GC> > box for me. How did you build libxml2 to avoid both the compilation and
GC> > run-time problem that I encountered (without speaking of mpatrol that I
GC> > think you might have skipped just as I did)?
GC> 
GC> I didn't. Until today, I didn't try the scripted "buildworld". I updated
GC> the compiler and used it to rebuild the C++ parts only.

 OK, this explains the other mystery of why you didn't run into these
issues, so I think almost everything is clear now.

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

 Regards,
VZ