Opened 13 years ago
Closed 13 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 |
Description
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 by , 13 years ago
Cc: | added |
---|
comment:2 by , 13 years ago
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 by , 13 years ago
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.
comment:4 by , 13 years ago
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 by , 13 years ago
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?
comment:6 by , 13 years ago
--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 by , 13 years ago
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
comment:8 by , 13 years ago
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 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
WARNING: XXX: EXPAT_CFLAGS = -I/usr/include WARNING: XXX: EXPAT_LDFLAGS = -L/usr/lib -lexpat
rouault, your commit seems to have fixed the problem.
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 ;-)