[Liblas-devel] libLAS-1.7.0b2 build issues: GTIFAtof and proj
hobu.inc at gmail.com
Tue Jul 26 09:58:51 EDT 2011
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
> // 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?
More information about the Liblas-devel