CC @sebastic

I'd rather see GRASS getting its act together and use FHS compliant paths for everything it installs thereby removing the need to set RUNPATH [1].

This is a simpler change that we've carried in the Debian package since before I got involved, but it's not a solution in itself.

As mentioned in the grass-dev thread [2], GRASS itself doesn't set RUNPATH causing drivers loaded via gdal-grass to fail when trying to load the NEEDED libraries.

I see. In this case this PR, just like the Debian patch, does not help.

A solution, as long as GRASS libraries are in non-standard directories, would be to create something like /etc/ld.so.conf.d/grass.conf if possible, but this is beyond my Makefile skills. Simply adding

echo "@GRASS_GISBASE@/lib" > /etc/ld.so.conf.d/grass.conf

to the install: section is probably not save.

Adding a non-standard library path to ld.so.conf is a violation of Debian policy as also mentioned in the thread on grass-dev:

https://lists.osgeo.org/pipermail/grass-dev/2022-February/095606.html

For an acceptable solution either GRASS needs to set RUNPATH to find its libraries in non-standard paths (then gdal-grass can do the same), or it needs to install the libraries in standard paths (and gdal-grass won't need RUNPATH either).

A pity. The GRASS startup mechanisms do set RUNPATH to find the GRASS libraries, but since the gdal-grass plugin is a library, I don't see how the gdal-grass plugin can set RUNPATH such that GRASS libraries find other GRASS libraries.

Therefore the only solution for the time being seems to be that users set LD_LIBRARY_PATH themselves before using the gdal-grass plugin.

/usr/bin/grass sets LD_LIBRARY_PATH to find the libraries in non-standard paths, if the GRASS build sets RUNPATH on the binaries and libraries the LD_LIBRARY_PATH work around won't be needed any more either.

With GRASS PR 2280 and this PR, the GDAL-GRASS plugin works without any further modifications to LD_LIBRARY_PATH or /etc/ld.so.conf.d/.

The GDAL project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 21 days and is being automatically marked as "stale". If you think this pull request should be merged, please check - that all unit tests are passing - that all comments by reviewers have been addressed - that there is enough information for reviewers, in particular

• link to any issues which this pull request fixes
• add a description of workflows which this pull request fixes
• add screenshots if applicable
• that you have written unit tests where possible In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request. If there is no further activity on this pull request, it will be closed in a week.

@rouault @sebastic can this PR be merged?

It's more useful now that GRASS sets RUNPATH.

@rouault Can this please be added to the upcoming GDAL 3.4.3? Thanks

ok I'm doing it, but it should be the responsibility of contributors to ensure they have backported their changes ahead of release time (tagging their pull requests with the "backport release/XXXX" label)

Thanks and sorry about not being aware of this procedure so far.