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.  


_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel

Reply via email to