On Jul 25, 2011, at 9:36 PM, Ben Discoe wrote: > I moved up from libLAS-1.6.0 to libLAS-1.7.0b2 today and encountered the > following two build failures. > > 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. > I am using GDAL 1.8.0 and libgeotiff-1.3.0. > > 1. src\gt_wkt_srs.cpp(953): error C3861: 'GTIFAtof': identifier not found > > 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: > > #ifdef CPL_SERV_H_INTERNAL > // We found the cpl_serv.h that's in GDAL > // Supply what may not be in GDAL > #if !defined(GTIFAtof) > # define GTIFAtof atof > #endif > #else > // We found the cpl_serv.h that's in libgeotiff > ....
I'll add a patch to gt_wkt_srs.cpp that does something similar to this. I added back GTIFAtof to GDAL 1.9+, but that doesn't solve the problem for 1.8-. > > 2. Link error: > geotiff.lib(geotiff_proj4.obj) : error LNK2019: unresolved external symbol > _pj_free referenced in function _GTIFProj4FromLatLong > > 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? Do you need to link to the stub library? proj_i.lib?_______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
