On Sun, Nov 30, 2025 at 3:53 AM Andres Freund <andres@anarazel.de> wrote:
> On 2025-11-28 15:40:19 -0500, Tom Lane wrote:
> > =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> > > On 2025-Nov-26, Jeff Davis wrote:
> > >> Inline pg_ascii_tolower() and pg_ascii_toupper().
> >
> > > I think this broke the CI on (some flavors of?) Windows. In
> > > https://cirrus-ci.com/task/6080935063453696
> > > I got
> >
> > > [19:09:39.518]
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
src/backend/postgres_lib.a.p/commands_event_trigger.c.obj:in function `filter_list_to_array':
> > > [19:09:39.518] c:\cirrus\build/../src/backend/commands/event_trigger.c:377:(.text+0x2a5): undefined reference to
`pg_ascii_toupper'
> >
> > That's bizarre. I checked recent cfbot rebuilds of some of my patches
> > and there's no problem, also just looking at port.h it's impossible
> > to see how this could happen. Some weird compiled-code caching
> > misbehavior in CI, perhaps?
>
> Yea, I suspect something with ccache is going wrong. We have before noticed
> problems with ccache on mingw, where it somehow used .o files from the wrong
> major versions, despite obviously the input files obviously not supposed to be
> matching. I don't know what could cause that...
To have compiled event_trigger.c without a warning about an undeclared
function and then generated an unresolvable symbol reference, I
suppose it must either have (1) failed to track the dependency on the
precompiled header (so ccache spat out a cached .o from before commit
ec4997a9 that it shouldn't have), or (2) failed to re-precompile the
header (so ccache spat out a cached .pch from before commit ec4997a9
that it shouldn't have and then this or some earlier build compiled a
broken .o)? Hmm...
