expat configure problem on MinGW

Lets make sure this gets fixed before beta2.

Fixed in trunk (r13256). Added new macro m4/ax_expat.m4

There are three options available: --with-expat, --with-expat-inc and --with-expat-lib. These options work the same way as Xerces options (--with-xerces, etc.) what's explained in long comment No 5 for #1988.

I'm closing it as fixed. Please reopen if problems occur.

Replying to mloskot:

Fixed in trunk (r13256). Added new macro m4/ax_expat.m4 There are three options available: --with-expat, --with-expat-inc and --with-expat-lib. These options work the same way as Xerces options (--with-xerces, etc.) what's explained in long comment No 5 for #1988. I'm closing it as fixed. Please reopen if problems occur.

The use of --with-expat-lib is at least confusing, since by reading m4/ax_expat.m4 it looks like it should rather be named something like --with-expat-flags.

I believe m4/ax_expat.m4 has a definite bug as it does not add -lexpats in line 103, i.e., if expat is requested but its' location is non-standard.

in addition I think it should be

LIBS="$LIBS -L$expat_prefix/lib -lexpat"

and not

expat_lib_flags="-L$expat_prefix/lib -lexpat"

Mateusz,

Try to address this before 1.5.1 release if possible.

Ari,

All -lib options are supposed to accept linker flags, but not only path to library. This is intentional behavior of options like: --with-xerces-lib, --with-oci-lib, etc.

Second, I'm not sure why you are suggesting to update LIBS inside the macro. Value of LIBS is updated inside configure.in, near line 1445 depending on expact detection result

if test "$HAVE_EXPAT" = "yes"; then
    LIBS="$EXPAT_LDFLAGS $LIBS"
fi

I'd prefer to not to pollute global variables inside macros, but to use macros output in configure.in. Is this approach not working?

The problem with lib_flags is (sorry for not explaining it above) that -lexpat gets into a wrong position (too early) in the compiler command line and the linking fails (at least in my attempts in MinGW and g++). $LIBS is the last thing on the command line and thus works.

Ari,

What about changing line 1446 in configure.in to read:

LIBS="$LIBS $EXPAT_LDFLAGS"

Could you test it with MinGW?

The tests in configure are of form

$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5

which now leads to

$ g++ -o conftest.exe -g -O2  -I/c/MinGW/include  -L/c/MinGW/lib -lexpat conftest.cpp
C:/DOCUME~1/ajolma/LOCALS~1/Temp/ccwDbaaa.o: In function `main':
c:/dev/gdal/conftest.cpp:7: undefined reference to `XML_ParserCreate'
c:/dev/gdal/conftest.cpp:8: undefined reference to `XML_ParserFree'
collect2: ld returned 1 exit status

but this works:

$ g++ -o conftest.exe -g -O2  -I/c/MinGW/include conftest.cpp  -L/c/MinGW/lib - lexpat

Hm. The importance of the order seems to be MinGW specific problem.

The line 1446 affects things that are *after* the expat tests in configure.

Ari,

because I'm not able to test anything under MinGW, I'd kindly ask you to patch the AX_LIB_XERCES macro.

Works in Linux and in MinGW with this patch:

Index: ax_expat.m4
===================================================================
--- ax_expat.m4	(revision 13995)
+++ ax_expat.m4	(working copy)
@@ -96,7 +96,7 @@
 
     if test -n "$expat_prefix"; then
         expat_include_dir="$expat_prefix/include"
-        expat_lib_flags="-L$expat_prefix/lib -lexpat"
+        expat_lib_flags="-L$expat_prefix/lib"
         run_expat_test="yes"
     elif test "$expat_requested" = "yes"; then
         if test -n "$expat_include_dir" -a -n "$expat_lib_flags"; then
@@ -117,6 +117,9 @@
         saved_LDFLAGS="$LDFLAGS"
         LDFLAGS="$LDFLAGS $expat_lib_flags"
 
+	saved_LIBS="$LIBS"
+	LIBS="$LIBS -lexpat"
+
         dnl
         dnl Check Expat headers
         dnl
@@ -176,6 +179,7 @@
 
         CPPFLAGS="$saved_CPPFLAGS"
         LDFLAGS="$saved_LDFLAGS"
+	LIBS="$saved_LIBS"
     fi
 
     AC_MSG_CHECKING([for Expat XML Parser])

This patch has a small bug and needs a further change as the above patch removes -lexpat from EXPAT_LDFLAGS later. Sorry, noticed this only in compile. This is really hairy.

I'm wondering if what follows is exactly in the field of this bug report, but some colleagues of mine are cross-compiling GDAL 1.5.0 (from a Linux 32bit host) for a Windows target and an ARM target.

They have run into problem with expat, since on the build system /usr/include/expat.h is available (as it's a default location listed in ax_expat.m4, when no option is specified for expat), and is picked up wrongly when cross-compiling. expat.h includes system headers that of course confuse mingw.

Adding --without-expat to ./configure solves the problem, so it is relatively minor.

The same applies for curl, with same consequencies.

It also probably applies for geos, but with no consequence, as geos_c.h doesn't include system headers.

(Basically, I tracked -I/usr/include in GDALmake.opt)

Ari,

I applied your patch (with the small fix) to trunk (r14399) and branches/1.5 (r14400)

Even,

I agree it's probably a minor problem, but patches are welcome, so we can solve it at least in some parts.