PG Bug reporting form <noreply@postgresql.org> writes:
> I encountered an incorrect $libdir expansion when loading a C-language
> function from a shared library.
I'm not sure if this is just a typo in your submission,
but:
> CREATE OR REPLACE FUNCTION test(integer)
> RETURNS integer
> AS '$libdir/../../../hol-lambdas/src/ext/l_udfs.so',
> 'l_test'
> LANGUAGE C
> STRICT;
This is looking for l_udfs.so, but the rest of your message
references lambda_udfs.so. That wouldn't be the cause would it?
> The issue depends on the surrounding directory names. With the PostgreSQL
> repository located under a differently named directory, the same build and
> SQL statement resolve the expected path.
The presence of "postgres" in the --prefix string affects whether
our Makefile.global decides to append an extra directory level to
pkglib_path:
pkglibdir = $(libdir)
ifeq "$(findstring pgsql, $(pkglibdir))" ""
ifeq "$(findstring postgres, $(pkglibdir))" ""
override pkglibdir := $(pkglibdir)/postgresql
endif
endif
That is, with your specified
--prefix=/home/testuser/projects/hol-postgres/install
the pkglib_path would be
/home/testuser/projects/hol-postgres/install/lib
but with, say,
--prefix=/home/testuser/projects/hol-postgrex/install
the pkglib_path would be
/home/testuser/projects/hol-postgrex/install/lib/postgresql
thus changing the number of ".."s needed in your example. Perhaps
that rule explains your results with different installation paths?
> I can provide the exact compiled values of PGBINDIR and PKGLIBDIR, the
> resulting runtime pkglib_path, and a patch or regression test if required.
I'm quite hesitant to change the behavior around this: it's stood for
decades and any change would certainly break a bunch of people's
build/install recipes.
regards, tom lane
