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

[Vadim Zeitlin]

On Thu, 24 Mar 2011 16:49:40 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2011-03-24 14:51Z, Vadim Zeitlin wrote:
GC>
GC> > 1. Should I try to understand why does linking xmllint fail
GC> 
GC> Yes, I think so.

 I finally did it (please accept my ritual but sincere excuses about the
long time needed to do it). The real problem was due to this libtool error
which came before and that I hadn't initially noticed:

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

        *** 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)
        *** The inter-library dependencies that have been dropped here will be
        *** automatically added whenever a program is linked with this library
        *** or is declared to -dlopen it.

        *** Since this library must not contain undefined symbols,
        *** because either the platform does not support them or
        *** it was explicitly requested with -no-undefined,
        *** libtool will only create a static version of it.

IMO the libtool logic is pretty broken here, at least under MSW the shared
and static libraries are absolutely not interchangeable, and so it should
exit with an error instead of switching to creating a static library of its
own volition and I even posted to libtool mailing list proposing to change
this

 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.

 So to fix this problem I had to explicitly add this path to LDFLAGS:

Index: install_libxml2_libxslt.make
===================================================================
--- install_libxml2_libxslt.make        (revision 5209)
+++ install_libxml2_libxslt.make        (working copy)
@@ -61,7 +61,7 @@
   --enable-shared \
   --with-debug \
   --without-python \
-  LDFLAGS='-lws2_32' \
+  LDFLAGS='-L/MinGW_/lib' \
        AR='$(mingw_bin_dir)/ar' \
        AS='$(mingw_bin_dir)/as' \
        CC='$(mingw_bin_dir)/gcc' \

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

 Alternative and perhaps better place to do this could be in the install
script itself, e.g.:

Index: install_msw.sh
===================================================================
--- install_msw.sh      (revision 5209)
+++ install_msw.sh      (working copy)
@@ -165,7 +165,7 @@
 make $coefficiency -f install_miscellanea.make clobber
 make $coefficiency -f install_miscellanea.make

-make $coefficiency -f install_libxml2_libxslt.make
+make $coefficiency -f install_libxml2_libxslt.make LDFLAGS=-L/MinGW_/lib

 make $coefficiency -f install_wx.make

But it seems that the LDFLAGS need to be specified somewhere for the build
to work.


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.

 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.

 Regards,
VZ