[lmi] libxml2 and threads [Was: Cross-compiling lmi from Linux to MSW]

[Greg Chicares]

Although you were talking about cross-compiling, I've encountered an
apparently similar problem with MinGW-w64 gcc-4.9.2 . We could keep
our old binaries, which continue to work; but I'd really like the
instructions in 'INSTALL' to work cleanly.

On 2016-01-14 01:35, Vadim Zeitlin wrote:
[...]
> I downloaded the version used in install_libxml2_libxslt.make:
> 
>       $ cd ~/src/3rdparty
>       $ wget 
> ftp://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.26.tar.bz2
>       $ tar xf libxml2-2.6.26.tar.bz2
> 
> and configured it from a separate build directory:
> 
>       $ mkdir ~/build/libxml2-msw
>       $ cd $_
>       $ ~/src/3rdparty/libxml2-2.6.26/configure \
>           --disable-static --enable-shared \
>           --with-{debug,schemas} --without-{iconv,modules,python,schematron} \
>           --prefix=$HOME/msw/i686-w64-mingw32 \
>           --build=x86_64-unknown-linux-gnu \
>           --host=i686-w64-mingw32 \
>           --without-threads
> 
> The first 2 lines contain the options used for the current build of libxml2
> as part of lmi, so I just took them unchanged. The prefix option is, of
> course, arbitrary, but you do need to use some non-standard directory to
> avoid mixing up cross-compiled and native files. The next 2 lines are
> almost self-explanatory too, just notice that you need to specify the
> --build value too for the ancient version of configure used by this (almost
> 10 year old) version of libxml2, it's not used for the more recent versions
> (but then I can't even regenerate configure for 2.6.26 as it uses obsolete
> features support for which has been removed since then).
> 
> The last line is the really questionable one: I had to use it to work
> around a compilation error in thread-related code due to configure
> erroneously detecting both pthreads and Win32 threads. As I said, fixing
> this is not completely trivial because configure is a generated file and
> I'd have to do some not completely trivial changes in configure.in to allow
> using it with the current autoconf versions. As lmi doesn't use threads
> currently, I just chose the simplest solution, but I don't like it at all,
> threads are not something exotic and best to be avoided nowadays and it's
> perfectly possible that lmi starts using them one of these days, especially
> as they're part of C++11. IMO the right thing to do would be to update to a
> newer libxml2 version in which this problem is fixed and not use this
> option.
> 
> Anyhow, when configured with these options you can just do
> 
>       $ make -s install
> 
> and, after waiting for hundreds of warnings to scroll by, get the DLL and
> the rest generated under ~/msw/i686-w64-mingw32.

Here's the error I get:

/bin/sh ./libtool --tag=CC --mode=compile /MinGW_/bin/gcc -DHAVE_CONFIG_H -I. 
-I. -I. -I./include -I./include  -DHAVE_WIN32_THREADS -D_REENTRANT    -DWIN32  
-g -O2 -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch 
-Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses 
-Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wredundant-decls -c -o threads.lo threads.c
 /MinGW_/bin/gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include 
-DHAVE_WIN32_THREADS -D_REENTRANT -DWIN32 -g -O2 -pedantic -W -Wformat -Wunused 
-Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat 
-Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith 
-Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -c threads.c  
-DDLL_EXPORT -DPIC -o .libs/threads.o
threads.c: In function 'xmlOnceInit':
threads.c:788:10: error: 'run_once' undeclared (first use in this function)
     if (!run_once.done) {
          ^
...
install_libxml2_libxslt.make:146: recipe for target 
'libxml2/2.6/libxml2-2.6.26' failed
make: *** [libxml2/2.6/libxml2-2.6.26] Error 2

I'll retry it with '--without-threads'. But let me ask a question about
this error message now, just because I looked at the source code and
would like to understand what went wrong.

#elif defined HAVE_WIN32_THREADS
...
static DWORD mainthread;
static struct
{
    DWORD done;
    DWORD control;
} run_once = { 0, 0 };
/* endif HAVE_WIN32_THREADS */

This library built successfully with mingw.org gcc-3.4.5 . What changed?
Is it that 'struct {...} foo = {...}' was legal C once, but is no longer?
Or is it that HAVE_WIN32_THREADS wasn't defined for gcc-3.4.5, so we never
actually compiled this block before? Just curious--this isn't worth a lot
of research. I'll commit a change to add '--without-threads' anyway.