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

[Ben Discoe]

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
    ....

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?

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20110725/88e25286/attachment.html