On Fri, Jul 09, 2021 at 10:06:18AM -0400, Tom Lane wrote:
> Noah Misch <noah@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().
