Re: [lmi] Testing build with native MinGW 4.9.1

[Greg Chicares]

On 2016-01-20 17:28, Vadim Zeitlin wrote:
> 
>  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:

So did I. Our emails crossed.

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

Same here. I suppose I could hunt down a 'bfd.h' that matches MinGW-w64's
'libiberty', but I'm more inclined to ditch 'mpatrol'. There had been
problems here in the past, and I erased these ancient comments in the
hope that the problems wouldn't occur again:

http://svn.savannah.nongnu.org/viewvc/lmi/trunk/install_mingw.make?root=lmi&r1=6443&r2=6480&diff_format=u
-# Some gcc archives distributed by MinGW contain a version of
-# 'libiberty.a' that's incompatible with the version provided with
-# binutils, so gcc's 'libiberty.a' is explicitly excluded: it seems
-# reasonable to expect binutils to provide a 'libiberty.a' that works
-# with the 'libbfd.a' it also provides. See:
-#   http://article.gmane.org/gmane.comp.gnu.mingw.user/6932/
-#     [2003-04-29T21:32:35Z from Danny Smith]
-# to learn why this may matter a great deal.

Today's missing 'bfd.h' is a different problem. But there are just
too many problems with mpatrol.

> I didn't spend much time on this because IMO mpatrol shouldn't be used at
> all nowadays

I tend to agree. But first...

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

Looks like it matches what I was about to commit; I'll make sure it does.

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

I'll apply these soon, too.

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

Wow. I'm very grateful that you found that problem and solved it.

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

I didn't. Until today, I didn't try the scripted "buildworld". I updated
the compiler and used it to rebuild the C++ parts only.