Allow linking statically to libgdal about liblas HOT 11 CLOSED

Regarding the part 1.

However: I wonder why GDAL is different than other libs in this case?
The libzip.a and libgeotiff.a I am using are found just fine currently.

The difference is, that the other libraries use CMake's find_library feature only, whereas FindGDAL.cmake module relies on gdal-config utility.

The part 2., I'd say this is a known issue, a PITA
http://lists.osgeo.org/pipermail/liblas-devel/2014-February/001583.html

from liblas.

The part 2., I'd say this is a known issue, a PITA http://lists.osgeo.org/pipermail/liblas-devel/2014-February/001583.html

I think that one is slightly different than the duplicate symbols problem? I also saw:

error: conflicting types for '_GTIFcalloc'

Which I figure is the clang equivalent to the error: declaration of C function ‘void* _GTIFcalloc(size_t)’ conflicts with... see in http://trac.osgeo.org/gdal/ticket/4374 which is linked from http://lists.osgeo.org/pipermail/liblas-devel/2014-February/001584.html. Which I think is basically the same as https://gist.github.com/hobu/8477865.

I solved this using this patch:

--- src/gt_wkt_srs.cpp_ 2014-04-05 23:26:08.000000000 -0700
+++ src/gt_wkt_srs.cpp  2014-04-05 23:28:26.000000000 -0700
@@ -31,8 +31,8 @@
  ****************************************************************************/

 #include "cpl_serv.h"
-#include "geo_tiffp.h"
 #define CPL_ERROR_H_INCLUDED
+#include "geo_tiffp.h"

 #include "geovalues.h"
 #include "ogr_spatialref.h"

from liblas.

Although to be clear: in my case of course I don't need to apply that patch because I needed remove compilation of src/gt_wkt_srs.cpp altogether to avoid linking problems. So they are clearly related but I think only the #define CPL_ERROR_H_INCLUDED fix might be needed to fix the compile when linking against a shared libgdal.dylib/so.

from liblas.

Right, they are slightly different. I meant, generally, GTiff/CPL symbols proved to be trouble makers one way or another.

from liblas.

Seems like this issue was fixed by 59709b3 b8799e5?

from liblas.

b8799e5 looks related yes, but not 59709b3 AFAICT

from liblas.

Copy-paste error on my end, original comment updated.

from liblas.

Just tested and confirmed that b8799e5 does fix the conflicting types for '_GTIFcalloc compile error. The same one seen at https://gist.github.com/hobu/8477865

However, the original issue behind this ticket was being able to statically link libgdal, which is not addressed at all by b8799e5. Instead you have to avoid the compilation of src/gt_wkt_srs.cpp completely to avoid this linking error:

duplicate symbol _GTIFGetOGISDefn in:
    CMakeFiles/las.dir/gt_wkt_srs.cpp.o
    /Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a(gt_wkt_srs.o)
duplicate symbol _GTIFSetFromOGISDefn in:
    CMakeFiles/las.dir/gt_wkt_srs.cpp.o
    /Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a(gt_wkt_srs.o)
duplicate symbol _GTIFWktFromMemBuf in:
    CMakeFiles/las.dir/gt_wkt_srs.cpp.o
    /Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a(gt_wkt_srs.o)
duplicate symbol _GTIFMemBufFromWkt in:
    CMakeFiles/las.dir/gt_wkt_srs.cpp.o
    /Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a(gt_wkt_srs.o)
ld: 4 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/Release/liblas.2.2.0.dylib] Error 1
make[1]: *** [src/CMakeFiles/las.dir/all] Error 2
make: *** [all] Error 2

from liblas.

Ah, right on. I see now how that second issue kinda just got dragged in — it does seem like the main issue is unresolved.

I just tried to build against the static GDAL and things went poorly. I don't have anything useful to contribute there ATM, unfortunately.

from liblas.

Sorry, I should have commented previously that I've had no problem working around this. I mostly filed the issue to just in case it helps others. The first FindGDAL issue I solved by doing https://github.com/mapnik/mapnik-packaging/blob/master/osx/patches/liblas-find-gdal.diff. And the linking errors can be solved by doing https://github.com/mapnik/mapnik-packaging/blob/master/osx/patches/liblas-skip-gt_wkt_srs.diff.

My usecase for linking to a static libgdal.a is not critical and a bit oddball. I've been learning to use las2ogr to dump lidar data to a shapefile for a side project https://gist.github.com/springmeyer/6016995 and I am in the habit of statically linking gdal for other projects so that I can come back to a project using gdal months later and be sure that other GDAL/homebrew upgrades did not break my las2ogr binary.

from liblas.

closing since the workarounds are easy and I doubt anyone else is going to be statically linking libgdal.a :)

from liblas.