lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Upgrading libxml2 and libxslt


From: Vadim Zeitlin
Subject: Re: [lmi] Upgrading libxml2 and libxslt
Date: Wed, 13 Jul 2016 23:33:08 +0200

On Wed, 13 Jul 2016 18:05:17 +0000 Greg Chicares <address@hidden> wrote:

GC> However, I run into difficulty with the following patch, which updates
GC> the libraries (causing '--without-threads' and '--without-zlib' to be
GC> suppressed in the makefile's 'configure' options).
GC> 
GC> --------8<--------8<--------8<--------8<--------8<--------8<--------
GC> 
GC> diff --git a/install_libxml2_libxslt.make b/install_libxml2_libxslt.make
GC> index 89a9c80..b1b65b1 100644
GC> --- a/install_libxml2_libxslt.make
GC> +++ b/install_libxml2_libxslt.make
GC> @@ -23,10 +23,10 @@
GC> 
GC>  # Archives and their md5sums
GC> 
GC> -libxml2_version = libxml2-2.6.26
GC> -libxslt_version = libxslt-1.1.17
GC> -#libxml2_version = libxml2-2.9.4
GC> -#libxslt_version = libxslt-1.1.29
GC> +#libxml2_version = libxml2-2.6.26
GC> +#libxslt_version = libxslt-1.1.17
GC> +libxml2_version = libxml2-2.9.4
GC> +libxslt_version = libxslt-1.1.29
GC> 
GC>  libxml2_archive := $(libxml2_version).tar.gz
GC>  libxslt_archive := $(libxslt_version).tar.gz
GC> 
GC> -------->8-------->8-------->8-------->8-------->8-------->8--------
GC> 
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.

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


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:

---------------------------------- >8 --------------------------------------
diff --git a/install_libxml2_libxslt.make b/install_libxml2_libxslt.make
index 89a9c80..6bfbdc1 100644
--- a/install_libxml2_libxslt.make
+++ b/install_libxml2_libxslt.make
@@ -23,10 +23,10 @@
 
 # Archives and their md5sums
 
-libxml2_version = libxml2-2.6.26
-libxslt_version = libxslt-1.1.17
-#libxml2_version = libxml2-2.9.4
-#libxslt_version = libxslt-1.1.29
+#libxml2_version = libxml2-2.6.26
+#libxslt_version = libxslt-1.1.17
+libxml2_version = libxml2-2.9.4
+libxslt_version = libxslt-1.1.29
 
 libxml2_archive := $(libxml2_version).tar.gz
 libxslt_archive := $(libxslt_version).tar.gz
@@ -83,8 +83,8 @@ common_options := \
   --build=i686-pc-cygwin \
   --host=i686-w64-mingw32 \
   --disable-dependency-tracking \
-  --disable-static \
-  --enable-shared \
+  --disable-shared \
+  --enable-static \
   --with-debug \
   --without-python \
   LDFLAGS='-lws2_32' \
diff --git a/msw_common.make b/msw_common.make
index 3761dd1..a9aabbd 100644
--- a/msw_common.make
+++ b/msw_common.make
@@ -36,7 +36,7 @@ SHREXT := .dll
 # and rarely needs to be updated.
 
 platform_defines := \
-  -DLIBXML_USE_DLL \
+  -DLIBXML_STATIC \
   -DSTRICT \
 
 platform_gui_ldflags := -mwindows
@@ -45,6 +45,8 @@ platform_gnome_xml_libraries := \
   -lexslt \
   -lxslt \
   -lxml2 \
+  -lz \
+  -lws2_32 \
 
 platform_wx_libraries := \
   -lwx_new \
---------------------------------- >8 --------------------------------------

 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.

 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. This is really
puzzling and I'd like to understand why does it happen even if we don't
want to use a static libxml2 library because something definitely seems to
be wrong here.

 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.

 Please let me know if you have any preferences here, thanks in advance,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]