Re: PostGIS in non-standard path

Scott <[email protected]> writes:

> Debian 12, PostGIS 3.6.0
>
> I've built postgis from source with all the latest libs, CGAL, SFCGAL,
> GDAL. My --prefix path is a non-standard location. Everything built
> and installed just fine.

Overall, you're suffering from the standard approach in Linux where
~everybody has ~everything in /usr and proper handling of prefix
(including dependencies) is not entirely right.  We often have to deal
with this in pkgsrc.  I'm unclear on the details in the postgis case.
Just warning you that you on less-trodden ground.  Also, I have the
impression that in some GNU/Linux distributions, there is a bias against
the use of RPATH, perhaps more than a bias, but my impressions are both
hazy and not recently formed.

> In pgsql, PostGIS is finding GEOS 3.11 in /usr, not the GEOS 3.14 in
> --prefix path, which gives me the error:

There are three separate "finding"s -- not sure which you mean:

  - build system detection
  - link at build time
  - dynlink at runtime

> My LD_LIBRARY_PATH is set, as is the postgres user and pgserver config
> dynamic_library_path. Is there some env variable I can use to set a
> lib path or other magic you can suggest on how I can fix this without
> removing GEOS 3.11? I know this is kinda wonky, but I thought I'd ask.

My view is that setting LD_LIBRARY_PATH at runtime is a bug, papering
over that the RPATH notes in the executables are wrong.

The right way -- sometimes easier said than done -- is one of:

  A) configure script has an explict --with-geos=/usr/newstuff, which leads
  to CPPFLAGS+=-I$P/include and LDFLAGS+="-L$P/lib -R$P/lib" (or some
  more 'modern' -Wl,-rpath equivalent).

  B) When invoking configure/build, you pass those args explicitly.

I routinely pass CPPFLAGS/LDFLAGS as option B, when I build various
things from repo checkouts for testing.  (pkgsrc does this automatically
as it wraps/replaces compiler flags in order to hide things not declared
as dependencies).

Note that with either A/B, if you end up with the situation where you
want foo from /usr and bar from /usr/newstuff, but both foo and bar
exist in both, then the dynamic linking system really can't deal with
that.

I am guessing your problem is lack of -R (-Wl,-rpath) in link lines for
postgis.  Fixing that maybe tricky, as
${base_prefix}/lib/postgresql/pgxs/src/ has postgresql Makefiles.

Also, having a postgresql module with a different path than postgresql
itself may well be trouble -- more not-well-trodden ground.


It's really useful to run 'objdump -x' to see what has been compiled in
for both NEEDED libraries and RPATH, and also ldd to see how things
resolve.  I've appended data from my NetBDS 10 amd64 system.  Note RPATH
having /usr/pkg/lib, ensuring libraries of the same name/major are
loaded from there ahead of /usr/lib.  (But, BSD systems have very little
in the base system, with most complicated things in a packaging system,
so it's really a different situation.  However if I were to add /usr/geo
for things built from source alongside /usr/pkg for standard packaging
and /usr for base, it would be analogous.  I package things, so I don't
tend to do that, instead just updating the package.)

$ objdump -x /usr/pkg/lib/postgresql/postgis-3.so |egrep NEEDED\|PATH
  NEEDED               libexecinfo.so.0
  NEEDED               libm.so.0
  NEEDED               libc++.so.1
  NEEDED               libgeos_c.so.1
  NEEDED               libproj.so.25
  NEEDED               libjson-c.so.5
  NEEDED               libprotobuf-c.so.1
  NEEDED               libxml2.so.16
  NEEDED               libpthread.so.1
  NEEDED               libz.so.1
  NEEDED               liblzma.so.2
  NEEDED               libc.so.12
  NEEDED               libstdc++.so.9
  RPATH                /usr/pkg/lib:/usr/X11R7/lib

$ ldd /usr/pkg/lib/postgresql/postgis-3.so 
/usr/pkg/lib/postgresql/postgis-3.so:
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.2 => /usr/lib/libelf.so.2
        -lc.12 => /usr/lib/libc.so.12
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lm.0 => /usr/lib/libm.so.0
        -lc++.1 => /usr/lib/libc++.so.1
        -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1
        -lgeos.3.14.0 => /usr/pkg/lib/libgeos.so.3.14.0
        -lstdc++.9 => /usr/lib/libstdc++.so.9
        -lproj.25 => /usr/pkg/lib/libproj.so.25
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lsqlite3 => /usr/pkg/lib/libsqlite3.so
        -ltiff.6 => /usr/pkg/lib/libtiff.so.6
        -llzma.2 => /usr/lib/liblzma.so.2
        -lLerc.4 => /usr/pkg/lib/libLerc.so.4
        -ljbig.2 => /usr/pkg/lib/libjbig.so.2
        -ljpeg.8 => /usr/pkg/lib/libjpeg.so.8
        -lz.1 => /usr/lib/libz.so.1
        -lcurl.4 => /usr/pkg/lib/libcurl.so.4
        -lnghttp2.14 => /usr/pkg/lib/libnghttp2.so.14
        -lidn2.0 => /usr/pkg/lib/libidn2.so.0
        -lunistring.5 => /usr/pkg/lib/libunistring.so.5
        -lintl.1 => /usr/lib/libintl.so.1
        -lssl.15 => /usr/lib/libssl.so.15
        -lcrypto.15 => /usr/lib/libcrypto.so.15
        -lcrypt.1 => /lib/libcrypt.so.1
        -ljson-c.5 => /usr/pkg/lib/libjson-c.so.5
        -lprotobuf-c.1 => /usr/pkg/lib/libprotobuf-c.so.1
        -lxml2.16 => /usr/pkg/lib/libxml2.so.16