[lmi] Testing build with native MinGW 4.9.1

[Vadim Zeitlin]

 Hello,

 I thought it would be useful to test the build after the latest changes,
so I did just this in my existing lmi VM (I plan to also do it in a fresh
one later). I ran into some problems:

1. Building mpatrol failed with the following error:

gcc -I../../src -I../../tools -O2 -c -osymbol.o ../../src/symbol.c
../../src/symbol.c:77:17: fatal error: bfd.h: No such file or directory
 #include <bfd.h>
                 ^
compilation terminated.
mpatrol-mingw-GNUmakefile:124: recipe for target 'symbol.o' failed
make[1]: *** [symbol.o] Error 1
make[1]: Leaving directory '/opt/lmi/mpatrol-scratch/mpatrol/build/windows'
install_mpatrol.make:106: recipe for target 'all' failed
make: *** [all] Error 2

I didn't spend much time on this because IMO mpatrol shouldn't be used at
all nowadays, it's quite obsolete by now and it's probably better to use a
dynamic instrumentation tool such as DrMemory (http://drmemory.org/)
instead. Better yet, build lmi under Linux with address (and/or undefined
behaviour_ sanitizer, which is much faster than DrMemory or Valgrind but
still finds most problems. So for now I've just skipped this step.


2. Building libxml and libxslt failed as well due to the problems that I've
already encountered when cross-compiling, see my post at

http://lists.nongnu.org/archive/html/lmi/2016-01/msg00006.html

I've fixed them in the same way as described there too, but rereading this
message I've realized that I forgot to attach this particular fix, so let
me attach it to this message instead. I also attach a couple of other minor
patches which are described in their commit messages, but please let me
know if you have any questions about them.


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


 To summarize, globally things look good but they didn't work out of the
box for me. How did you build libxml2 to avoid both the compilation and
run-time problem that I encountered (without speaking of mpatrol that I
think you might have skipped just as I did)?

 Thanks,
VZ

0001-Fix-libxslt-compilation-problem-with-mkdir-with-MinG.patch
Description: Text document

0002-Disable-thread-support-in-libxml2-to-fix-build-with-.patch
Description: Text document

0003-Disable-support-for-the-compressed-files-in-libxml2.patch
Description: Text document

0004-Consistently-use-i686-w64-mingw32-host-option-value.patch
Description: Text document