Building (configure) fails in some 64bit linux environments

[Ari Jolma]

In a 64bit system, which has both 32bit and 64bit versions of a library (for example expat - not an unusual situation I believe), configure may add -L/usr/lib into GDALmake.opt, which may end up in "wrong architecture" failure in link stage. I assume the culprits are m4/ax_expat.m4 and such, which seem to add /usr/lib to LIBS.

The result is that the configure may not find all libraries, but it finishes. make fails at link stage, but removing /usr/lib's from GDALmake.opt fixes that problem.

[Even Rouault]

Do you have a particular example of a Linux distribution where this happens ? This would mean that /usr/lib would have 32 bit libraries in a 64bit system ? Sounds odd. Or did you try building 32 bit GDAL on that 64 bit system ?

I think specifying --with-expat-lib should enable you to specify the right directory.

CC'ing Mateusz as I see his name in ax_expat.m4 ;-)

[Ari Jolma]

In one Red Hat Enterprise Linux I work on we have both 64bit libexpat and 32bit libexpat. Both are from a regular package and other packages depend on them. 32bit libexpat is in /usr/lib and 64bit one is in /usr/lib64. That particular RHEL is rather standard I believe - although I've added some things because of GDAL. I tried configure --with-expat-lib (shortly) but I believe it is not enough.

However, I'm rather new with 64bit systems, so maybe I'm missing something. Shouldn't the build work out of the box without any specific build flags or similar also in a 64bit system? In any case the only problem is those /usr/lib's in LIBS of GDALmake.opt.

[Ari Jolma]

BTW, here's the build log (rebuilt every night from now on):

​http://map.hut.fi/files/Geoinformatica/snapshots/build.log

I've added a simple perl skript to fix the GDALmake.opt between configure and make.

[Even Rouault]

Interesting... On Ubuntu 64 bit (and Debian probably), my /usr/lib has the 64 bit libs, and /usr/lib32, the 32 bit ones... Might be interesting to see how other software packages solve this.

[Mateusz Łoskot]

Here is recent discussion about similar issue:

​/usr/lib/libexpat.so found when /usr/lib64/libexpat.so needed

and it looks like ./configure --without-libtool may be helpful.

Here is another similar thread:

​/usr/lib/libexpat.so: could not read symbols: File in wrong format

where it's confirmed --with-expat-lib=/usr/lib64 may be helpful.

Ari, could you confirm if any of these solutions work for you?

[Ari Jolma]

--with-expat-lib=/usr/lib64 makes configure find expat so that's fine but the main problem - -L/usr/lib in LIBS in GDALmake.opt - remains. I'm not sure if the expat test code puts it there or what. It may even be that libtool or some other external tool puts it there. The problem is not finding the expat lib or compilation but linking (that's also the case in the latter mail if you look at the output).

./configure --without-libtool --with-expat-lib=/usr/lib64 also results -L/usr/lib in LIBS in GDALmake.opt

[Mateusz Łoskot]

The AX_LIB_EXPAT macro should set EXPAT_LDFLAGS=/usr/lib64 as it sets there whatever is given with --with-expact-lib​ and assigns the EXPAT_LDFLAGS​ with this value.

Then, configure.in does concatenate EXPAT_LDFLAGS​ with other LIBS.

The question is what really goes to EXPAT_LDFLAGS in your environment.

Ari, could you try this:

• in line 189 of ax_expat.m4​ file, before AC_SUBST, add these two lines

AC_MSG_WARN([XXX: EXPAT_CFLAGS = $EXPAT_CFLAGS])
AC_MSG_WARN([XXX: EXPAT_LDFLAGS = $EXPAT_LDFLAGS])

• run ./autogen.sh
• run ./configure
• see what flags these two XXX messages output

[Even Rouault]

Hum, I've commited a change in trunk in r18833 while Mateusz was making his last comment. This should avoid putting -L/usr/lib or -L/usr/lib64 and let the compiler find itself the path. Could you update and test (without your hack to remove -L/usr/lib) ?

[Ari Jolma]

 WARNING: XXX: EXPAT_CFLAGS = -I/usr/include
 WARNING: XXX: EXPAT_LDFLAGS = -L/usr/lib -lexpat

rouault, your commit seems to have fixed the problem.