Re: pgsql: aix: No need to use mkldexport when we want to export all symbol

Hi,

On 2022-09-12 23:39:04 -0700, Noah Misch wrote:
> On Mon, Sep 12, 2022 at 11:11:23PM -0700, Andres Freund wrote:
> > On 2022-09-12 20:38:45 -0700, Noah Misch wrote:
> > > On Sun, Sep 11, 2022 at 11:19:25AM -0700, Andres Freund wrote:
> > > Both runs had the latest commits discussed above. tern (gcc32) passed, but it
> > > doesn't use --with-perl.
> >
> > I'll check it out tomorrow. I configured perl on the other AIX gcc compile
> > farm machine building 64bit with both gcc and xlc, IIRC. I can't check rn,
> > they seem to be down?
>
> They're up.

Yep, seems to have been temporary.

> > What is "perl64-for-gcc"?
>
> ===
> #! /bin/sh
>
> real_perl=perl64
>
> case $* in
> '-MExtUtils::Embed -e ldopts' | \
> '-MConfig -e print $Config{ccdlflags}')
> $real_perl "$@" | sed 's/-b/-Wl,-b/g' ;;
> *)
> exec $real_perl "$@" ;;
> esac
> ===

I guess that defeats our plperl flags logic - the wrapper shouldn't be needed
anymore today, see my parallel message about the problem likely being caused
by -Wl,-bE:.

> > > > > -qvisibility option specifies visibility attributes for entities. Entity
> > > > > visibility attributes describe whether and how entities defined in one
> > > > > module can be referenced or used in other modules. Visibility attributes
> > > > > affect entities with external linkage only, and cannot increase the
> > > > > visibility of other entities.
> > > >
> > > >
> > > > Since xlc 13.1 supports all still supported AIX versions I'm inclined to think
> > > > we should increase our requirement to 13.1 rather than revert back to the
> > > > higher complexity way of building modules.
> > >
> > > Perhaps. That would demolish two buildfarm members.
> >
> > Or you could update them to a slightly newer xlc? IIRC the machine has 13.x
> > available?
>
> I don't see 13.x, but I might not know where to look.

Looks like it's not available on gcc111, just on gcc119, there it's at
/opt/IBM/xlc/13.1.3/bin/xlc

> > > What does PostgreSQL lose if you revert fe6a64a?
> >
> > A somewhat readable Makefile.shlib. The prior state is complicated, specific
> > to AIX. I've several times spent quite a bit of time understanding it - not
> > helped by the complete lack of comments. It's not frequent enough to stay in
> > my brain unfortunately, so I'll have to relearn it again next time. And we'll
> > need to continue supporting Makefile.shlib for quite a while, so ...
>
> I'm voting for a revert, then. Code beautification is nice when it just
> works, but desupporting this compiler to land this particular code
> beautification makes the net value go negative for me. I can understand your
> feeling differently based on your recent experiences.

IMO this more than just a beautification - the difference is functional in
nature. I'd agree if it just were a reformating or such, but this isn't that.

I just tested, and with the mlkdexport.sh approach we end up with all symbols
exported (-fvisibility=hidden) in extension .so's - AIX will be the only
platform unable to restrict symbol exports. That's bound to lead to problems
we'll only have on AIX.

The more special-case-y some platform is, the higher the cost of supporting it
is. I'm somewhat ok with supporting niche stuff, but then the people desiring
that support also need to do the work of making that bearable for everyone
else.

Greetings,

Andres Freund