[Liblas-devel] libLAS-1.7.0b2 build issues: GTIFAtof and proj static

[Howard Butler]

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?