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

[Peder Axensten]

I wish I could help to implement it myself, but I don't even know first things about cmake or make. I would suggest that the following would be the default paths (if they are available on the specific Mac OS X machine):
	GDAL_INCLUDE_DIR		/Library/Frameworks/GDAL.framework/Headers
	GDAL_LIBRARY			/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib
	GEOTIFF_INCLUDE_DIR	/Library/Frameworks/UnixImageIO.framework/Headers
	GEOTIFF_LIBRARY		/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib
	TIFF_INCLUDE_DIR		/Library/Frameworks/UnixImageIO.framework/Headers
	TIFF_LIBRARY			/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib
This makes it very straightforward to first install GDAL using the KyngChaos binary as suggested and then liblas.

Would that be feasible?

On 20 feb 2011, at 21.06, Howard Butler wrote:

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

Until it can be fixed, maybe a note in the install instructions? It took me awhile to actually *see* the difference, then it was easy to fix...

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

I forgot I'm no longer on a PPC – it's not an issue for me. :-)

Regards,
Peder