Opened 15 years ago
Closed 15 years ago
#2602 closed defect (fixed)
./configure --with-hdf4 fails, but ./configure --with-hdf4=/usr/lib works
Reported by: | Even Rouault | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.6.0 |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | hdf4 |
Cc: |
Description
Without path:
./configure --without-libtool --with-hdf4 [SNIP] In GDALmake.opt LIBS = [SNIP] -L -lmfhdf -ldf [SNIP]
In the report at end of configure, hdf4 is indicated as being build, but the "-L -lmfhdf -ldf" in the LIBS line is wrong.
With path:
./configure --without-libtool --with-hdf4=/usr/lib [SNIP] LIBS = [SNIP] -L/usr/lib -lmfhdf [SNIP]
correct, and builds fine
Interesting, this is a trunk only problem. With branches/1.5 svn, ./configure --with-hdf4 works
Change History (5)
comment:1 by , 15 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | hdf4 added |
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Ok, I've fixed configure.in in r15505. I've tested successfully ./configure --with-hdf4, ./configure --with-hdf4=yes, ./configure --with-hdf4=/usr and ./configure --with-hdf4=/usr/lib
configure needs to be regenerated
comment:4 by , 15 years ago
regenerated (r15506). Is this change something that belongs in 1.5 as well?
comment:5 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
tanks. no, this is trunk only. This was a regression apparently
By doing a diff on both configure.in, there are clearly changes. The configure.in in trunk looks suspicious for the --with-hdf4 case