expat configure problem on MinGW

[warmerdam]

Tim reports (via email) that for gdal 1.5.0beta1:

./configure fails for me (on Ubuntu 7.10), but works fine with 1.4.4 and earlier.

...
checking for MySQL... no
checking for Xerces C++ Parser... no
checking for Expat C++... requested, but compile or link fails!

g++ -I/usr/include -o conftest conftest.cpp -L/usr/lib -lexpat -lpq
-L/usr/local/pgsql/lib -lpq -lz -lm -lrt -ldl

conftest.cpp:1:19: error: expat.h: No such file or directory
conftest.cpp: In function 'int main()':
conftest.cpp:2: error: 'XML_Parser' was not declared in this scope
conftest.cpp:2: error: expected `;' before 'p'
conftest.cpp:2: error: 'p' was not declared in this scope
conftest.cpp:2: error: 'XML_ParserFree' was not declared in this scope

cat conftest.cpp
#include <expat.h>
int main() {  XML_Parser p = XML_ParserCreate(NULL);
XML_ParserFree(p); }
configure: error: Please correct Expat options, or don't enable Expat.

I can send full config.log if you want it.

Regards, Tim Bowden

[warmerdam]

Lets make sure this gets fixed before beta2.

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

[ajolma]

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.

[ajolma]

in addition I think it should be

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

and not

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

[warmerdam]

Mateusz,

Try to address this before 1.5.1 release if possible.

[mloskot]

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?

[ajolma]

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.

[mloskot]

Ari,

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

LIBS="$LIBS $EXPAT_LDFLAGS"

Could you test it with MinGW?

[ajolma]

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.

[mloskot]

Ari,

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

[ajolma]

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])

[ajolma]

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.

[rouault]

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)

[mloskot]

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.