Re: [xml] build problem with libxslt-1.1.9 on mingw/win32

[Igor Zlatkovic <igor zlatkovic com>]

On 31/08/04 14:01, Stefan Kost wrote:
> Hi Igor,
>
> I'll try the configure.js outside msys tomorrow morning.
>
> == extra libs ==
> Now here are some more details. When compiling libxml2 under msys using
> configure one needs to add -lwsock32, otherwise all the nannoftp stuff does not
> link.
>
> When compiling libxslt more libs need to be added, because there are undefined
> symbols and that disabled making a shared library out of it.
>
> E:/msys/bin/sh.exe ../libtool --mode=link gcc  -I/gnuwin32/include
> -I/opt/include -fno-builtin -mno-cygwin -mms-bitfields -Wall -L/mingw/lib
> -L/gnuwin32/lib -L/opt/lib -lwsock32 -o libexslt.la -rpath /opt/lib
> -version-info 8:7:8  exslt.lo common.lo crypto.lo math.lo sets.lo functions.lo
> strings.lo date.lo saxon.lo dynamic.lo ../libxslt/libxslt.la -L/opt/lib -lxml2
> -liconv
>
> *** Warning: This system can not link to static lib archive ../libxslt/libxslt.la.
> *** 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.
> libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared
> libraries
> ar cru .libs/libexslt.a  exslt.o common.o crypto.o math.o sets.o functions.o
> strings.o date.o saxon.o dynamic.o
> ranlib .libs/libexslt.a
> creating libexslt.la
>
> == mkdir in libxslt/security.c ==
> 'libxslt-1.1.9/libxslt/win32config.h'
> defines the compatibillity wrapper for mkdir, but in
> 'libxslt-1.1.9/libxslt/libxslt.h'
> includes by 'security.c' the following statement disables the inclusion
> #if defined(WIN32) && !defined (__CYGWIN__) && !defined (__MINGW32__)
> #include <win32config.h>
> #else
> #include "config.h"
> #endif

I can remember this being a pain a while ago. The problem was that 
native Mingw needed a different treatment than  the one run through MSYS 
or Cygwin. But there is no way to check for this in the code, means 
there is no preprocessor macro which tells you whether you run MSYS or 
just Mingw.

How about banning that win32config.h file? config.h is generated on Unix 
by GNU Autoconf. We could also have the win32/configure.js generate 
config.h, for example by copying and possibly modifying win32config.h. 
That removes all those conditions in the code. The code always includes 
config.h then and the configure script, whichever it happens to be, 
takes care of its contents.

If you want to do this, go ahead. I am extremely busy at the moment, 
looking for an appartment in Munich, which I must find until the end of 
the next week.

Ciao,
Igor