I moved up from libLAS-1.6.0 to libLAS-1.7.0b2 today and encountered the following two build failures.<br><br>I am using VC10, using WITH_GDAL and WITH_GEOTIFF defined in CMake for libLAS, because i'm trying/hoping to handle ECEF CRS in LAS as WKT.<br>
I am using GDAL 1.8.0 and libgeotiff-1.3.0.<br><br>1. src\gt_wkt_srs.cpp(953): error C3861: 'GTIFAtof': identifier not found<br><br>There is logic at the top of gt_wkt_srs.cpp which seems to say, if we got cpl_serv.h from libgeotiff instead of from GDAL, then we may need to define GTIFAtof. However, GTIFAtof isn't defined in GDAL 1.8.0 either, so i had to fix it like this:<br>
<br>#ifdef CPL_SERV_H_INTERNAL<br> // We found the cpl_serv.h that's in GDAL<br> // Supply what may not be in GDAL<br>#if !defined(GTIFAtof)<br># define GTIFAtof atof<br>#endif<br>#else<br> // We found the cpl_serv.h that's in libgeotiff<br>
....<br><br>2. Link error: <br>geotiff.lib(geotiff_proj4.obj) : error LNK2019: unresolved external symbol _pj_free referenced in function _GTIFProj4FromLatLong<br><br>My libgeotiff seems to want PROJ4 static. (Although PROJ4 is almost never static; AFAIK it's dynamic by default with all versions of GDAL, and it's dynamic on my machine too.) I can manually add proj.lib to my link line for liblas, but CMake is supposed to be making liblas build files that work already. Do we need a "PROJ4_IS_STATIC" option in the liblas CMake files to support this?<br>
<br>Thanks,<br>Ben<br><br>