[postgis-devel] [geos-devel] MacOS DYLD Fix

[Greg Troxel]

Paul Ramsey via postgis-devel <postgis-devel at lists.osgeo.org> writes:

>> On Nov 10, 2023, at 3:46 PM, Regina Obe <lr at pcorp.us> wrote:
>> 
>> This isn’t an issue with other projects besides PostGIS that use GEOS?
>> Perhaps related, how much trouble would it be to get PostGIS to use pkgconfig for GEOS.  I see that GEOS does ship pkgconfig files.
>
> We could probably do it on a going-forward basis, but per usual we’d
> end up with all the old code *plus* the pkgconfig code, so it wouldn’t
> really “clean up” anything. There are autoconf macros already in
> configure.ac doing pkgconfig stuff on other deps, so not too too hard
> of an add.

We need the old code because postgis allows geos that is too old for
pkgconfig?   I lean to use pkgconfig if it exists and then drop support
for not-pkgconfig when geos that doesn't do it ages out.

>>  It’s always annoying when I try to do it that I have to explicitly
>> specify the geos-config file in PostGIS when in other cases, we can
>> read the pkg-config and have in fact standardized on that for other
>> dependencies we use.
>>  
>> I’ve added PostGIS dev to this since well we seem to be talking about PostGIS now.
>
> I’m honestly at a bit of a loss as to whether installing with an rpath
> and expecting linking software to set an appropriate search path is
> the right thing, or locking in a fixed installation location is the
> right thing. Certainly the latter results in less nonsense in the
> postgis build. But it broke proj, which had some tests that expected
> to be able to manually move an installation post-install.

Software that searches for a library should (again speaking normally not
macOS-ish), should after finding the lib in prefix

  add -I$prefix/include to CPPFLAGS

  add
    -L$prefix/lib -Wl,-R$prefix/lib -lfoo
  to LDFLAGS/LDADD 
  
or however R, rpath, should be.

this is basically from pkgconfig's misnamed flags:

  $ pkg-config --cflags geos; pkg-config --libs geos
  -I/usr/pkg/include
  -L/usr/pkg/lib -lgeos_c

Installed pkgconfig files often get this wrong and omit the rpath.
That's ok to do if $prefix/lib is in the system's default search path,
which it isn't in this case.

glib, in contrast, produces:

  $ pkg-config --cflags glib-2.0; pkg-config --libs glib-2.0
  -I/usr/pkg/include/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include
  -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lglib-2.0 -lintl


For pkgsrc, this missing -R is not in practice a problem in almost all
cases because almost everything is in /usr/pkg (or /opt/pkg, but the
same place) and there is an overall -R for that.  When things are in a
subprefix (for parallel installation of multiple versions), it matters
more.

For Debian and most GNU/Linux distributions, everything is in /usr and
thus in the default path.


Running objdump -x on /usr/pkg/lib/libgeos_c.so:

  NEEDED               libgeos.so.3.12.0
  NEEDED               libstdc++.so.9
  NEEDED               libm.so.0
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.12
  SONAME               libgeos_c.so.1
  RPATH                /usr/pkg/lib

and that seems right.  That RPATH really is needed formally as one
cannot assume that the program linking in geos_c has RPATH, only that it
found geos_c.

It sounds like the issue is that macOS does things differently and we
weren't ending up with the equivalent of RPATH set on macOS builds?