Re: buildfarm warnings

I wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
>> Is there any check for warnings from new code, other than those buildfarm
>> members with -Werror ?

> I periodically grep the buildfarm logs for interesting warnings.
> There are a lot of uninteresting ones :-(, so I'm not sure how
> automatable that'd be. I do use a prefiltering script, which
> right now says there are
> 13917 total warnings from 41 buildfarm members
> of which it thinks all but 350 are of no interest.

This conversation motivated me to take a fresh pass over said filtering
script, and one thing I notice that it's been ignoring is these complaints
from all the AIX animals:

ld: 0711-224 WARNING: Duplicate symbol: .xml_is_well_formed
ld: 0711-224 WARNING: Duplicate symbol: xml_is_well_formed

while building contrib/xml2. Evidently this is because xml2 defines
a symbol also defined in the core. We cannot rename xml2's function
without a user-visible ABI break, but it would be pretty painless
to rename the core function (at the C level, not SQL level).
So I propose we do that. I think that when I put in that pattern,
there were more problems, but this seems to be all that's left.

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.

regards, tom lane