Actually looking at the wiki page, I've just updated it since it would
not have worked if the system PROJ is >= 6.0. The update consists in
adding -DPROJ_INTERNAL_CPP_NAMESPACE to CXXFLAGS when building PROJ so
that C++ symbols of the "internal" proj don't clash with the ones of the
system PROJ (that was Docker build recipees already did)
Le 26/08/2021 à 17:35, Even Rouault a écrit :
Patrick,
I guess this is at least relevant for the ubuntu-full config that uses
libspatialite from the distro. This libspatialite must link against
proj 6.3.1 from the Ubuntu 20.04 distro, whereas the GDAL we build
will link against the PROJ built in the image, so without that trick,
crashes would happen.
Even
Le 26/08/2021 à 17:21, Patrick Young a écrit :
Hi,
I was curious how relevant building an internal PROJ library is these
days as described in this note
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev
<https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev>
I noticed GDAL's docker builds still do this. Are there some common
dependencies that still use the older PROJ?
Many thanks!
Patrick
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
