Re: [lmi] Upgrading libxml2 and libxslt

[Greg Chicares]

On 2016-07-13 21:33, Vadim Zeitlin wrote:
> On Wed, 13 Jul 2016 18:05:17 +0000 Greg Chicares <address@hidden> wrote:

[...failure building current libxml2 to use zlib...]

> GC> Here's the problem AFAICT:
> GC> 
> GC> *** Warning: linker path does not have real file for library -lz.
> GC> *** I have the capability to make that library automatically link in when
> GC> *** you link to this library.  But I can only do this if you have a
> GC> *** shared version of the library, which you do not appear to have
> 
>  Yes, this is indeed the problem, libtool refuses to link a static library
> into a DLL because of a completely stupid idea that because it doesn't work
> on some platforms (like Linux/x86_64), it shouldn't do it anywhere, even
> under MSW where it works without any problems. Unfortunately I've already
> tried discussing this with libtool developers and it was amazingly useless,
> people on libtool mailing list just refuse to accept this as being a
> problem at all, so there is absolutely no hope for solving it.

Sounds like the same story we saw here:
  http://lists.gnu.org/archive/html/libtool-patches/2011-06/msg00001.html
  [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.

>  OTOH while looking into this the last time, I did learn enough about
> libtool to know how to patch it to skip this check and force libtool to
> create libxml2 DLL linking with zlib statically. So I could do this and it
> would work, but it would require applying a patch to libxml2 sources and
> this patch might not be simple to update for any normal person who doesn't
> deal in libtool internals...

That is a real disadvantage...

> GC> *** libtool will only create a static version of it.
> 
>  If we can live with the static version of libxml2, then the simplest fix
> would certainly be to just build it, i.e. apply the following patch:
[...]
>  However I don't know if it's acceptable, clearly the existing makefiles
> intentionally prefer to build the shared version and, normally, this is a
> better idea as libxml2 is used by several targets and using a shared
> library avoids duplicating its code in all of them.

The whole point of libtool is to make this sort of thing work easily.
It seems very wrong to avoid using a shared library because of a defect
in libtool.

>  Also, applying this patch and rebuilding everything results in plenty of
> build errors for me when using the official makefiles and I just can't
> understand why: somehow, all symbols from liblmi.dll are not found any more
> even though I don't seem to have changed anything for it.

I think we already had enough reason not to use a static libxml2.
Now we have another strong reason.

>  And if we really need to use libxml2 as a DLL, I see only two options:
> 
> 1. Get and build zlib DLL ourselves too.
> 2. Use a custom makefile for libxml2 and link in (static) zlib into it.
> 
>  Neither is very appealing but I think (1) is better. Unless we're ready to
> live with a patch to libtool.

How about:

3. Download an official build, and verify its md5sum
42eccc2af5bac6b7a1188d7817d03549 as given here:
  http://www.zlib.net/

$wget http://zlib.net/zlib128-dll.zip
$md5sum zlib128-dll.zip
42eccc2af5bac6b7a1188d7817d03549 *zlib128-dll.zip

I'm going to try this, at least as a proof of concept. If it fixes the
libxml2 problem described above, then we can decide whether we prefer
to download this library or build it ourselves from source.