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

[Greg Chicares]

On 2011-06-16 15:30Z, Vadim Zeitlin wrote:
[...]
>       ... during libxml2 make ...
>       /bin/sh ./libtool --tag=CC --mode=link /MinGW_/bin/gcc  -g -O2 
> -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wco
>       mment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized 
> -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wa
>       ggregate-return -Wstrict-prototypes -Wmissing-prototypes 
> -Wnested-externs -Winline -Wredundant-decls  -lws2_32 -o libxml2.la -rpath
>       /opt/lmi/local/lib -no-undefined -version-info 8:26:6  SAX.lo 
> entities.lo encoding.lo error.lo parserInternals.lo parser.lo tree.lo
>       hash.lo list.lo xmlIO.lo xmlmemory.lo uri.lo valid.lo xlink.lo 
> HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo xpointer.lo xinclude.l
>       o nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo threads.lo 
> c14n.lo xmlstring.lo xmlregexp.lo xmlschemas.lo xmlschemasty
>       pes.lo xmlunicode.lo xmlreader.lo relaxng.lo dict.lo SAX2.lo 
> xmlwriter.lo legacy.lo chvalid.lo pattern.lo xmlsave.lo xmlmodule.lo sc
>       hematron.lo   -lws2_32

My most recent (successful) log has a line that's probably identical:

/bin/sh ./libtool --tag=CC --mode=link /MinGW_/bin/gcc  -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  -lws2_32 -o libxml2.la
-rpath /opt/lmi/local/lib -no-undefined -version-info 8:26:6  SAX.lo 
entities.lo encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo 
list.lo xmlIO.lo xmlmemory.lo uri.lo valid.lo
xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo xpointer.lo xinclude.lo 
nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo threads.lo c14n.lo 
xmlstring.lo xmlregexp.lo xmlschemas.lo
xmlschemastypes.lo xmlunicode.lo xmlreader.lo relaxng.lo dict.lo SAX2.lo 
xmlwriter.lo legacy.lo chvalid.lo pattern.lo xmlsave.lo xmlmodule.lo 
schematron.lo   -lws2_32

but it succeeds, and is followed immediately by:
  /MinGW_/bin/gcc -shared  [...] .libs/schematron.o  -lws2_32  -o 
.libs/libxml2-2.dll [...]
  Creating library file: .libs/libxml2.dll.a
whereas you get the dreaded...

>       *** Warning: linker path does not have real file for library -lws2_32.
>       *** I have the capability to make that library automatically link in 
> when
>       *** you link to this library.  But I can only do this if you have a
>       *** shared version of the library, which you do not appear to have
>       *** because I did check the linker path looking for a file starting
>       *** with libws2_32 but no candidates were found. (...for file magic 
> test)

You must have a ws2_32 DLL somewhere, right?
  $ls /cygdrive/c/WINDOWS/system32/ws2_32*
  /cygdrive/c/WINDOWS/system32/ws2_32.dll
Isn't that the "shared version of the library" that libtool wants?
My (msw-xp) $PATH contains "C:\WINDOWS\system32"; could it be that
you're using a 64-bit OS that doesn't expose any '*_32.dll'? I think
I've read, on the Cygwin mailing list, that 32-bit libraries may be
in a ghostly subdirectory that isn't really there--I can try to find
a reference if it would help, but maybe you already know what I'm
trying to say.

>  But the real problem is, of course, that it can't find ws2_32 library in
> the first place. I don't really understand how does it work for everyone
> else but it doesn't seem surprising that it doesn't work for me, there
> doesn't seem to be any reason for Cygwin libtool to know about /MinGW_/lib
> directory that contains libws2_32.a file even if MinGW compiler does look
> in this directory by default.

Are you using exactly the same nearly-minimal Cygwin installation as we are,
as produced by 'install_cygwin.bat'? I'm just wondering whether you have your
own Cygwin with extra components that take precedence over the MinGW stuff.
OTOH, that may not matter, because our libtool comes from Cygwin:
  $ls -l /bin/libtool
  -rwxr-xr-x 1 Arktos root 322116 2010-09-23 19:48 /bin/libtool

> Notice that I removed the explicit -lws2_32 as it doesn't seem to be needed
> anyhow, libxml configure correctly add this library when building for MinGW
> (and not for Cygwin).

Confirmed. I'll remove it from 'install_libxml2_libxslt.make' thus:
   --without-python \
-  LDFLAGS='-lws2_32' \
        AR='$(mingw_bin_dir)/ar' \
after testing on a virgin xp box just to be sure.

> GC> > 2. Shouldn't the build stop if any of dependencies fail to build?
> GC> 
> GC> The libxml2 makefile terminates as you'd expect, but the 'install_msw.sh'
> GC> script keeps going...for no good reason. (The machines in our office are
> GC> so slow that the script has to be run overnight anyway, so it doesn't
> GC> matter whether they stop as soon as a fatal error occurs.) I guess 'set 
> -e'
> GC> isn't what we really want because it ignores commands that aren't 
> "simple",
> GC> so should I make a change like
> GC>   -make $coefficiency -f install_libxml2_libxslt.make
> GC>   +make $coefficiency -f install_libxml2_libxslt.make || exit 3
> GC> for each line that calls for early termination on failure?
> 
>  This would, of course, work. I don't know if it should be preferred to
> "set -e" though. On one hand, "set -e" is annoying because it can abort the
> script even on "clearly" harmless errors but OTOH it does catch all of
> them, whereas there is always potential for forgetting to check something
> with explicit checks.

That sounds like a conclusive reason *not* to use 'set -e', because...

> GC> (The machines in our office are
> GC> so slow that the script has to be run overnight anyway, so it doesn't
> GC> matter whether they stop as soon as a fatal error occurs.)

...and we can't afford to have overnight runs abort on harmless "errors".

>  In any case, it would be really nice if the script could be modified to
> abort on error as I now have another one ("ld.exe: cannot find -lexslt")
> during the build of LMI itself but it still happily says "Finished building
> lmi." and I had to dig into the log file again to see why wasn't it really
> built.

It's intended to be usable even by people who don't know what a shell script
is for. If it fails, then all they can do is send me their log; and early
exits won't really make it easier for me to diagnose their problems.

However, it's most often used by Wendy or me. It takes about an hour to run
on my dedicated test machine, and it would be nice to have it stop after
fifteen minutes if it's certain to fail. But that's not a high priority,
and because of its intended use we spend a lot of time testing every change
rigorously, so I might not take the time to change it soon. Couldn't you
get the behavior you prefer if you manually specify 'set -e'?