Re: [lmi] Upgrading libxml2 and libxslt

[Vadim Zeitlin]

On Fri, 15 Jul 2016 18:03:57 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-07-14 16:04, Vadim Zeitlin wrote:
GC> > On Thu, 14 Jul 2016 15:15:15 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> >  And if we really need to use libxml2 as a DLL, I see only two 
options:
GC> > GC> > 
GC> > GC> > 1. Get and build zlib DLL ourselves too.
GC> > GC> > 2. Use a custom makefile for libxml2 and link in (static) zlib into 
it.
...
GC> > GC> 3. Download an official build, and verify its md5sum
...
GC> Yes, (1) would be best, but it's not trivial to build a shared library:
GC> 
GC> /tmp[0]$wget http://zlib.net/zlib-1.2.8.tar.gz
GC> /tmp[0]$tar -xvf /cache_for_lmi/downloads/zlib-1.2.8.tar.gz
GC> /tmp[0]$cd zlib-1.2.8
GC> /tmp/zlib-1.2.8[0]$export PATH="/MinGW_/bin:${PATH}"
GC> /tmp/zlib-1.2.8[0]$gcc -dumpversion
GC> 
GC> 4.9.1
GC> /tmp/zlib-1.2.8[0]$./configure
GC> 
GC> Checking for gcc...
GC> 
GC> Checking for shared library support...
GC> 
GC> No shared library support.
...
GC> but I still get "No shared library support". I can't understand what
GC> 'configure' is doing here, but perhaps you can spot the problem easily.

 Unfortunately this "configure" is, in spite of its name, a manually
written script and not something generated by autoconf, so it took me some
time to understand this but I do indeed see what it is doing now and the
way to work around the problem above is to do the following:

        % export LDSHARED='gcc -shared'
        % export LDSHAREDLIBC=''
        % PATH=/MinGW_bin:$PATH ./configure
        % PATH=/MinGW_bin:$PATH make -s

This still produces libz.so.1.2.8 and not the expected libz.dll on output
however. It looks functional and we could just rename it to libz1.dll and
use it but we'd lose at least the version information from the
win32/zlib.rc file which doesn't get linked in this case, so, on balance...

GC> Here is one alternative that seems to work:
GC> 
GC> /tmp/zlib-1.2.8[0]$make -f win32/Makefile.gcc

... this still seems to be better. The main drawback here is that it strips
the library, while I'd prefer to keep the symbols, but this is relatively
minor.

GC> but if we do that, then the process presumably won't work under
GC> GNU/Linux.

 I don't think we should worry about this, I've never seen any Linux system
without libz.so, so we're never going to build it there anyhow.

 Regards,
VZ