On Mon, Feb 14, 2022 at 6:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Another thing I've been ignoring on the grounds that I-don't-feel-
> like-fixing-this is that the Solaris and OpenIndiana machines whine
> about every single reference from loadable modules to the core code,
> eg this from haddock while building contrib/fuzzystrmatch:
>
> Undefined first referenced
> symbol in file
> cstring_to_text dmetaphone.o
> varstr_levenshtein fuzzystrmatch.o
> text_to_cstring dmetaphone.o
> errstart_cold fuzzystrmatch.o
> errmsg fuzzystrmatch.o
> palloc dmetaphone.o
> ExceptionalCondition fuzzystrmatch.o
> errfinish fuzzystrmatch.o
> varstr_levenshtein_less_equal fuzzystrmatch.o
> repalloc dmetaphone.o
> errcode fuzzystrmatch.o
> errmsg_internal fuzzystrmatch.o
> pg_detoast_datum_packed dmetaphone.o
> ld: warning: symbol referencing errors
>
> Presumably, this means that the Solaris linker would really like
> to see the executable the module will load against, analogously to
> the BE_DLLLIBS settings we use on some other platforms such as macOS.
> It evidently still works without that, but we might be losing
> performance from an extra indirection or the like. And in any case,
> this amount of noise would be very distracting if you wanted to do
> actual development on that platform. I'm not especially interested
> in tracking down the correct incantation, but I'd gladly push a patch
> if someone submits one.
I took a quick look at this on an OpenIndiana vagrant image, using the
GNU compiler and [Open]Solaris's linker. It seems you can't use -l
for this (it only likes files called libX.Y) but the manual[1] says
that "shared objects that reference symbols from an application can
use the -z defs option, together with defining the symbols by using an
extern mapfile directive", so someone might need to figure out how to
build and feed in such a file...
[1] https://docs.oracle.com/cd/E26502_01/html/E26507/chapter2-90421.html