Paul Ramsey via postgis-devel <postgis-de...@lists.osgeo.org> writes:
>> On Nov 10, 2023, at 3:46 PM, Regina Obe <l...@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? _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel