Date: Mon, 12 Sep 2022 23:39:04 -0700
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: aix: No need to use mkldexport when we want to export all
 symbol
Message-ID: <20220913063904.GB1439680@rfd.leadboat.com>
References: <325593.1662783266@sss.pgh.pa.us>
 <89D645BA-FF97-4516-A21D-9FC4A4B31F8C@anarazel.de>
 <20220910043749.koidc5k4j5dxo3if@awork3.anarazel.de>
 <20220910052741.t7w7csyrggwus2ze@awork3.anarazel.de>
 <338810.1662787972@sss.pgh.pa.us>
 <20220910055736.htsr5juo3ldlay2l@awork3.anarazel.de>
 <20220910081944.oiayp5lky3kv2o43@awork3.anarazel.de>
 <20220911181925.ygxbync3uk5ezcic@awork3.anarazel.de>
 <20220913033845.GA1439680@rfd.leadboat.com>
 <20220913061123.mxae5udw6ix2op7v@awork3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220913061123.mxae5udw6ix2op7v@awork3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220913063904.GB1439680%40rfd.leadboat.com>
Precedence: bulk

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:
> > > On 2022-09-10 01:19:44 -0700, Andres Freund wrote:
> > > > On 2022-09-09 22:57:36 -0700, Andres Freund wrote:
> > > > > On 2022-09-10 01:32:52 -0400, Tom Lane wrote:
> > > > > > Andres Freund <andres@anarazel.de> writes:
> > > > > > > It seem worth applying the -qvisibility patch and seeing whether that fixes
> > > > > > > the buildfarm?
> > > > > >
> > > > > > Worth a try.
> > > > >
> > > > > Done now.
> > > >
> > > > Seems to have done the trick for at least hoverfly. And wrasse (sunpro) is
> > > > still happy. Still need to wait for the older xlc's (mandril, hornet)
> > > > though...
> > >
> > > At least hornet isn't happy:
> > >
> > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2022-09-10%2021%3A44%3A00
> > >
> > > Looks like the support for -qvisibility came with xlc 13.1, released April 28, 2014:
> > > https://www.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS214-162
> >
> > Last two sungazer (gcc64) runs failed with a suspicious "missing magic block":
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2022-09-12%2006%3A24%3A53
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2022-09-10%2018%3A09%3A11
> >
> > 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.

> 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
===

> > > > -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.

> > 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.