On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote: > >> What I'm now thinking about is restricting the test to only be run on > >> platforms where use of foo.a libraries is deprecated, so that we can > >> be pretty sure that we won't hit this situation. Even if we only > >> run the test on Linux, that'd be plenty to catch any mistakes. > > > Hmm. Static libraries are the rarer case on both AIX and Linux, but I'm not > > aware of a relevant deprecation on either platform. If it comes this to, > > I'd > > be more inclined to control the Makefile rule with an environment variable > > (e.g. ENFORCE_LIBC_CALL_RESTRICTIONS) instead of reacting to the platform. > > That'd require buildfarm owner intervention, as well as intervention > by users. Which seems like exporting our problems onto them. I'd > really rather not go that way if we can avoid it.
I like that goal, though we'll have to see how difficult it proves. As of today, a GNU/Linux user building against static OpenLDAP will get a failure, right? That would export work onto that user, spuriously. Since the non-AIX user count dwarfs the AIX user count, expect a user complaint from non-AIX first. We'd get something like 95% of the value by running the test on one Windows buildfarm member and one non-Windows buildfarm member. If you did gate the check on an environment variable, there would be no need to angle for broad adoption. Still, I agree avoiding that configuration step is nice, all else being equal. A strategy not having either of those drawbacks would be to skip the test if libpq.so contains a definition of libpq_unbind(). If any other dependency contains exit calls, we'd likewise probe for one symbol of that library and skip the test if presence of that symbol reveals static linking. (That's maintenance-prone in its own way, but a maintenance-free strategy has not appeared.)
