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

[Nikos Alexandris]

* Markus Metz <markus.metz.giswork at gmail.com> [2020-02-03 22:35:26 +0100]:

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

(Is there a good reason not to provide for `make uninstall` besides
more workload? --I actually have no idea what it takes to do so!)

>Generally, cleaning up should happen in
>${prefix}/lib[64]
>${prefix}/include
>${prefix}/share

Do you create yourself a "hardcoded" list of files you need to remove?
Otherwise, it's a time consuming hunting of files here and there.

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

That I forgot to remove :D.
Won't existing files be overwritten by `make install` as root?

>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

Thank you Markus, Nikos