Re: [lmi] error building libxml using install_msw.sh

[Greg Chicares]

[oops, sent to VZ rather than to ML]

On 2011-06-17 16:46Z, Vadim Zeitlin wrote:
> On Fri, 17 Jun 2011 15:41:51 +0000 Greg Chicares <address@hidden> wrote:
[...]
> > >  But the real problem is, of course, that it can't find ws2_32 library in
> > > the first place.
> 
>  So, to summarize, I still believe this is the case. I'd love to know
> where and how does it find it on your system. If you could temporarily
> modify your libtool to show the libraries it finds, it would be great. A
> simple way to do it is to search for "but no candidates are found" in
> /opt/lmi/xml-scratch/libxml2-2.6.26/libtool script and then insert
> 
>       echo "!!! $potlib"
> 
> before "break 2" line 12 lines above it (I guess I could make an ed script
> to do this but it's probably faster to do it interactively). After this you
> can run the command
> 
>       ./libtool --tag=CC --mode=link /MinGW_/bin/gcc  -g -o libxml2.la \
>               -rpath /opt/lmi/local/lib -no-undefined -version-info 8:26:6 \
>               *.lo -lws2_32
> 
> interactively in /opt/lmi/xml-scratch/libxml2-2.6.26 directory. What does
> it output for you?

/usr/bin[0]$cd "C:\opt\lmi\xml-scratch\libxml2-2.6.26"
/opt/lmi/xml-scratch/libxml2-2.6.26[0]$diff -U3 libtool-restoreme libtool
--- libtool-restoreme   2011-06-17 15:18:09.392051100 +0000
+++ libtool     2011-06-17 17:01:00.000000000 +0000
@@ -4009,6 +4009,7 @@
                         | $EGREP "$file_magic_regex" > /dev/null; then
                        newdeplibs="$newdeplibs $a_deplib"
                        a_deplib=""
+            echo "!!! $potlib"
                        break 2
                      fi
                  done
@@ -4061,6 +4062,7 @@
                        | $EGREP "$match_pattern_regex" > /dev/null; then
                      newdeplibs="$newdeplibs $a_deplib"
                      a_deplib=""
+              echo "!!! $potlib"
                      break 2
                    fi
                  done

[i.e., I patched it in both places; and here's the output:]

/opt/lmi/xml-scratch/libxml2-2.6.26[0]$./libtool --tag=CC --mode=link /MinGW_/bi
n/gcc  -g -o libxml2.la \
>               -rpath /opt/lmi/local/lib -no-undefined -version-info 8:26:6 \
>               *.lo -lws2_32
rm -fr  .libs/libxml2.a .libs/libxml2.la
!!! C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../..//libws2_32.a

/MinGW_/bin/gcc -shared  .libs/DOCBparser.o .libs/HTMLparser.o .libs/HTMLtree.o
.libs/SAX.o .libs/SAX2.o .libs/c14n.o .libs/catalog.o .libs/chvalid.o .libs/debu
gXML.o .libs/dict.o .libs/encoding.o .libs/entities.o .libs/error.o .libs/global
s.o .libs/hash.o .libs/legacy.o .libs/list.o .libs/nanoftp.o .libs/nanohttp.o .l
ibs/parser.o .libs/parserInternals.o .libs/pattern.o .libs/relaxng.o .libs/schem
atron.o .libs/testdso.o .libs/threads.o .libs/tree.o .libs/uri.o .libs/valid.o .
libs/xinclude.o .libs/xlink.o .libs/xmlIO.o .libs/xmlmemory.o .libs/xmlmodule.o
.libs/xmlreader.o .libs/xmlregexp.o .libs/xmlsave.o .libs/xmlschemas.o .libs/xml
schemastypes.o .libs/xmlstring.o .libs/xmlunicode.o .libs/xmlwriter.o .libs/xpat
h.o .libs/xpointer.o  -lws2_32  -o .libs/libxml2-2.dll -Wl,--enable-auto-image-b
ase -Xlinker --out-implib -Xlinker .libs/libxml2.dll.a
Creating library file: .libs/libxml2.dll.a
creating libxml2.la
(cd .libs && rm -f libxml2.la && ln -s ../libxml2.la libxml2.la)

[end of libtool output]

So the information you wanted is:
!!! C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../..//libws2_32.a
which simplifies to:
  C:/opt/lmi/MinGW-20090203/lib/libws2_32.a
which is probably present in your MinGW installation as it is in mine:

/opt/lmi/xml-scratch/libxml2-2.6.26[0]$ls -l 
/cygdrive/c/opt/lmi/MinGW-20090203/lib/libws2_32.a
-rw-r--r--+ 1 Arktos None 83372 2008-12-06 02:31 
/cygdrive/c/opt/lmi/MinGW-20090203/lib/libws2_32.a

I hope that helps.

> GC> It's intended to be usable even by people who don't know what a shell 
> script
> GC> is for. If it fails, then all they can do is send me their log; and early
> GC> exits won't really make it easier for me to diagnose their problems.
> 
>  How do they even know that it failed though? It doesn't even output an
> error in this case.

Ah...they may not know what a shell script is for, but they know what an
illustration system is supposed to look like. And, in this business, vendors
often ship illustration systems that utterly fail to run, so end users know
how to recognize that situation.

>  Anyhow, what should we do about the ws2_32.dll problem? I could install 32
> bit Win7 system and repeat all of it there which would allow to at least
> detect whether the problem is 64-bit-specific. Or we could just add
> -L/opt/lmi/MinGW-.../lib option as I suggested because it definitely
> shouldn't hurt anything.

Okay, then we should change 'install_libxml2_libxslt.make' as follows?

   --without-python \
-  LDFLAGS='-lws2_32' \
+  LDFLAGS='-L/opt/lmi/MinGW-.../lib' \
        AR='$(mingw_bin_dir)/ar' \

Oops--'-L/opt/lmi/MinGW-.../lib' won't work, and we'd need to spell out the
exact path to the compiler. Of course, we want the compiler version to remain
configurable; but we can't use '/MinGW_/' because that's a posix mount, right?
So do we have to use the 'cygpath' program here? Would you mind writing that
line, because I don't have the OS under which the problem is observed?

I'm pretty unhappy with this, because it makes these scripts more Cygwin-
dependent than they have to be, and we've avoided 'cygpath' everywhere else.
And libtool somehow knows the msw-native path to the compiler:

# Compile-time system search path for libraries
sys_lib_search_path_spec=" 
=C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/ 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/ /mingw/lib/gcc/mingw32/3.4.5/ 
/usr/lib/gcc/mingw32/3.4.5/
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/mingw32/3.4.5/
 C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/
/mingw/mingw32/lib/mingw32/3.4.5/ /mingw/mingw32/lib/ /mingw/lib/mingw32/3.4.5/ 
/mingw/lib/ 
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../mingw32/3.4.5/
C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../ 
/mingw/lib/mingw32/3.4.5/ /mingw/lib/ /lib/mingw32/3.4.5/ /lib/ 
/usr/lib/mingw32/3.4.5/ /usr/lib/"

Isn't there any way to use that information, which libtool already has?

>  In the meanwhile I can't help but notice that this is yet another problem
> that would have been much simpler to debug and actually probably wouldn't
> have occurred at all if we didn't use this unstable mix of MinGW and
> Cygwin. The fact that many paths are not understood by a half of tools used
> surely makes the life more interesting, especially considering that it's a
> different half every time... I'm just ranting, of course, as I realize that
> there is no chance of any big changes to the build system in the near
> future but anything at all, either MinGW/MSYS

Been there, done that, even got the T-shirt:
  http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html
The most awful shortcomings of MSYS have been alleviated since then,
but it still depends on one or two volunteers, and it could slide
back into un-maintained-ness any time. A burnt child dreads the fire.

> or Cygwin on its own

Then we'd rely on Cygwin's gcc toolchain. One problem is that they
update packages asynchronously, keeping only one earlier version
and deleting everything older than that. And we'd have to distribute
'cygwin1.dll', which is okay philosophically, but creates one more
task for someone to do. And the program would probably behave
differently, because msvcrt and newlib are different, and both have
their own problems. And it'd probably run slower than a native
application.

But I think Charles Wilson has just released a MinGW cross-compiler
for Cygwin, and that'd probably be a better choice for us than using
Cygwin's own gcc to write Cygwin-dependent programs. Still, we'd have
to upgrade from gcc-3.4.5 to 4.x, and we haven't managed to do that
with MinGW yet...but if we're going to consider any change along
these lines, then moving to gcc-4.x is the first step.

> or even
> MSBuild with cmd.exe, would be better than the current setup IMO.

The right goal is probably cross-building from GNU/Linux, so moving
to CMD.EXE would be a step in the wrong direction. It changes from
one OS version to another, often in startling ways, and I've spent
too much time compensating for its yickiness over the decades.
Besides, we use zsh for other tasks as well as building software.