[GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Markus Metz]

Hi Nikos,

On Mon, Feb 3, 2020 at 7:28 PM Nikos Alexandris <nik at nikosalexandris.net>
wrote:
>
> >>I got it working, more or less. Recompiling only PROJ did away most of
> >>the errors but a few. I guess I need to recompile PROJ (+GEOS), then
> >>GDAL, then the rest.
> >
> >Still need to fix a few more:
> >
> >Errors in:
> >/osgeo/grass/general/g.proj
> >/osgeo/grass/general/g.region
> >/osgeo/grass/raster/r.horizon
> >/osgeo/grass/raster/r.sun
> >/osgeo/grass/raster3d/r3.out.netcdf
> >
> >```
>
> Fixed, I had to remove left-over files from previous PROJ
> installation(s).
>
> (...why is there no `make uninstall` for PROJ, GEOS, etc.?)

if you compile from source, it is mostly your responsibility to clean up
old installations. Generally, cleaning up should happen in
${prefix}/lib[64]
${prefix}/include
${prefix}/share

regarding PROJ, cleaning up ${prefix}/share with the proj.db and grids is
quite important because PROJ is evolving fast and any leftovers from a
previous installation might confuse software compiled against PROJ.

Regarding GDAL compilation against PROJ, there was in GDAL 2 the configure
option
--with-static-proj4=ARG Compile with PROJ.4 statically (deprecated, use
--with-proj instead) (ARG=no or path)
in GDAL 3 there is only
--with-proj=ARG Compile with PROJ.x (ARG=yes or path)

This static proj linking in GDAL does not mean to link against a static
PROJ library, but to statically link against a given dynamic PROJ library,
i.e. the same PROJ library used at compile time will also be used at run
time. This is important to make sure that GDAL is not suddenly picking a
different PROJ library at run time when a new PROJ library becomes
available.

I ran in all these problems myself when adding support for PROJ 4, 5, and 6
in GRASS.

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20200203/ee4de6de/attachment-0001.html>