[Liblas-devel] Problems (and solutions) installing liblas 1.6.0 on Mac OS X

[Howard Butler]

On Feb 20, 2011, at 3:46 AM, Peder Axensten wrote:

> On Mac OS X 10.6.6 there are a few issues with the liblas installation, at least on my machine. These problems occurred on a copy of the active source code. I also tried the latest release, but it seems to have the same issues.
> 
> A basic installation works well, but 
> 
> Using WITH_GDAL it gets the wrong GDAL_LIBRARY path. It works if I change it manually to
> /Library/Frameworks/GDAL.framework/unix/lib/libgdal
> (It does get GDAL_INCLUDE_DIR right: /Library/Frameworks/GDAL.framework/Headers)

This needs to be added to the library finding code.

> 
> Using WITH_LASZIP it gets the wrong LASZIP_INCLUDE_DIR. It gets it to
> /usr/local/bin, changing it manually to /usr/local/include fixes it.

I've had this one show up from time to time too, but I haven't been able to reliably track down what causes it.  I'll look again and see.

> 
> Using WITH_ENDIANAWARE I got
> liblas/src/point.cpp: In member function ‘uint16_t liblas::Point::GetIntensity() const’:
> liblas/src/point.cpp:563: error: no matching function for call to ‘bitsToInt(uint16_t&, const std::vector<unsigned char, std::allocator<unsigned char> >&, size_t&)’
> liblas/src/point.cpp: In member function ‘uint16_t liblas::Point::GetPointSourceID() const’:
> liblas/src/point.cpp:791: error: no matching function for call to ‘bitsToInt(uint16_t&, const std::vector<unsigned char, std::allocator<unsigned char> >&, size_t&)’
> make[2]: *** [src/CMakeFiles/las.dir/point.cpp.o] Error 1
> make[1]: *** [src/CMakeFiles/las.dir/all] Error 2
> make: *** [all] Error 2

Fixed. http://trac.liblas.org/ticket/214

WITH_ENDIANAWARE is unfortunately named.  Enabling that switch intends to use code to do runtime endian aware data copies.  As Mike said, this is really only relevant on big endian boxen, and it is much faster to not enable it if you know you're working in a little-endian environment.  With OS X, this is now almost always the case, but with 10.6 and XCode, you can cross-compile things back to PowerPC. It is possible to build an XCode project that makes this easy to manage, but I don't know how to do it.  Additionally, this code hasn't actually been tested on SPARC or any big endian box as far as I know, so expect some hiccups if you're serious about needing big endian support for libLAS (and I know for sure big endian is not supported on LASzip at this time -- contact Martin with some contracting language if you need it :).

The moral of the story is don't use WITH_ENDIANAWARE unless you know you need it.