On Fri, Jul 09, 2021 at 10:06:18AM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote: > >> 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. > > As a former packager for Red Hat, my response would be "you're doing it > wrong". Nobody on any Linux distro should *ever* statically link code > from one package into code from another, because they are going to create > untold pain for themselves when (not if) the first package is updated. > So I flat out reject that as a valid use-case. > > It may be that that ethos is not so strongly baked-in on other platforms.
Packagers do face more rules than users generally. > But I'm content to wait and see if there are complaints before rescinding > the automatic test; and if there are, I'd prefer to deal with it by just > backing off to running the test on Linux only. Okay. > > We'd get something like 95% of the value by running the test on one Windows > > buildfarm member and one non-Windows buildfarm member. > > True. But that just brings up the point that we aren't running the test > at all on MSVC builds right now. I have no idea how to do that, do you? I don't. But coverage via non-MSVC Windows is good enough. > > ... A strategy not having either of those drawbacks would be to skip > > the test if libpq.so contains a definition of libpq_unbind(). > > I assume you meant some OpenLDAP symbol? Yeah, that was supposed to say ldap_unbind().
