Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain - Mailing list pgsql-hackers

On Mon, Dec 22, 2025 at 1:24 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Dec 22, 2025 at 11:48 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > fairywren's still not happy, though only in the v16 branch:
> >
> > Could not determine contrib module type for test_cloexec
> >  at build.pl line 54.
> >
> > This evidently is because the old MSVC build system doesn't
> > recognize
> >
> > PROGRAM += test_cloexec
> > OBJS += $(WIN32RES) test_cloexec.o
> >
> > Is there a reason for using += not just = here?  We could certainly
> > modify Mkvcbuild.pm to parse this if we need to, but it looks more
> > like a gratuitous difference from everyplace else than a useful
> > behavior.
>
> Yeah.  Will drop the + signs.  I've also written a patch to enable a
> separate "Windows - Server 2022, VS 2019 - Mkvcbuild.pm" CI task
> alongside the Meson one in the REL_16_STABLE branch.  I had run the
> affected branches through CI, but of course 16 switched to Meson so it
> wasn't testing the third build system... without that, this is just
> too painful.  I need to step away for a couple of hours, but more in a
> bit...

That revealed another problem: Mkvcbuild.pm didn't add -lpgport.  It
looks out for the pattern PG_LIBS_INTERNAL = $(libpq_pgport), so
that's an easy way to fix that -- is there a better way?  I couldn't
figure out how to tell it that we need libpqport but not libpq.
Here's a CI run of these patches on top of REL_16_STABLE, showing the
new Mkvcbuild.pm task passing:

https://cirrus-ci.com/build/5900754273173504