Opened 11 years ago

Closed 11 years ago

#3411 closed defect (fixed)

Building (configure) fails in some 64bit linux environments

Reported by: Ari Jolma Owned by: warmerdam
Priority: normal Milestone:
Component: ConfigBuild Version: unspecified
Severity: normal Keywords:
Cc: Mateusz Łoskot


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.

Change History (9)

comment:1 Changed 11 years ago by Even Rouault

Cc: Mateusz Łoskot added

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

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by Ari Jolma

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

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

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by Mateusz Łoskot

Here is recent discussion about similar issue:

/usr/lib/ found when /usr/lib64/ needed

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

Here is another similar thread:

/usr/lib/ 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?

comment:6 Changed 11 years ago by 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

comment:7 Changed 11 years ago by 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, 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
  • run ./
  • run ./configure
  • see what flags these two XXX messages output

comment:8 Changed 11 years ago by 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) ?

comment:9 Changed 11 years ago by Ari Jolma

Resolution: fixed
Status: newclosed
 WARNING: XXX: EXPAT_CFLAGS = -I/usr/include
 WARNING: XXX: EXPAT_LDFLAGS = -L/usr/lib -lexpat

rouault, your commit seems to have fixed the problem.

Note: See TracTickets for help on using tickets.