Ensure rpath is used for libgeos_c.so

[strk]

This ensures each C library links to its corresponding C++ library

Closes GH-1435

[strk]

This would need to be backported up to 3.8 branch

[mwtoews]

Perhaps I'm overthinking it, but it might be better to structure this similar to geosop:

geos/util/geosop/CMakeLists.txt

Lines 28 to 36 in cf85984

	if(NOT DEFINED CMAKE_INSTALL_RPATH)
	# Use relative rpath
	if(APPLE)
	set_target_properties(geosop PROPERTIES
	INSTALL_RPATH "@loader_path/../${CMAKE_INSTALL_LIBDIR}")
	else()
	set_target_properties(geosop PROPERTIES
	INSTALL_RPATH "\$ORIGIN/../${CMAKE_INSTALL_LIBDIR}")
	endif()

which would allow CMAKE_INSTALL_RPATH to override this (if needed) from a command line configuration.
As for the macOS handling, I'm unsure (as I'm aware you are) how to go with, as I can only read what others have done (e.g. here); probably go with "@loader_path". Or just handle if(NOT APPLE) to side-step macOS (mis-)configuration.

[strk]

Thanks for the review, pushed handling of override and APPLE

[pramsey]

I'm unsure why things "just work" on MacOS (or why @strk seems uniquely to have problems with Linux? none of this stuff is net new or recently changed). While the libgeos_c on Mac does reference to C++ library, the RPATH attribute is not set, so there's nothing forcing @rpath to resolve to the install location

otool -L libgeos_c.1.21.0.dylib

libgeos_c.1.21.0.dylib:
	@rpath/libgeos_c.1.dylib (compatibility version 1.0.0, current version 1.21.0)
	@rpath/libgeos.3.15.0.dylib (compatibility version 3.15.0, current version 3.15.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2000.67.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

[pramsey]

Ah, I see now that in MacOS, the geos_c library is inheriting an LC_RPATH from the postgis.dylib which points to the install location. I guess it does make sense of geos_c to itself know where to fine its deps, although anything which uses geos_c will itself need to be able to find it, and presumably has its own install rpath search directory set to the geos install location. This is one of those cases where a best practice sure would be nice, and there are a million ways to tune these dials.

[strk]

@pramsey the problem arose in php-geos CI recipe, which installs many different versions of GEOS in different paths, but it never needed to set LD_LIBRARY_PATH when GEOS was installed with automake, as the RPATH was written in the libgeos_c.so itself. I guess there are not many people installing multiple GEOS versions and those who do maybe prefer using a workaround rather than reporting a regression (this is a regression).