Thread: Broken make dependency somewhere near win32ver.o?

Broken make dependency somewhere near win32ver.o?

From
Thomas Munro
Date:
Hi,

Here's a strange one-off failure seen on CI[1], in the
CompilerWarnings task where we check that mingw cross-compile works:

[10:48:29.045] time make -s -j${BUILD_JOBS} world-bin
[10:48:38.705] x86_64-w64-mingw32-gcc: error: win32ver.o: No such file
or directory
[10:48:38.705] make[3]: *** [Makefile:44: pg_dumpall] Error 1
[10:48:38.705] make[3]: *** Waiting for unfinished jobs....
[10:48:38.709] make[2]: *** [Makefile:43: all-pg_dump-recurse] Error 2
[10:48:38.709] make[2]: *** Waiting for unfinished jobs....
[10:48:38.918] make[1]: *** [Makefile:42: all-bin-recurse] Error 2
[10:48:38.918] make: *** [GNUmakefile:21: world-bin-src-recurse] Error 2

I guess this implies a dependency problem somewhere around
src/makefiles/Makefile.win32 but I'm not familiar with how that .rc
stuff is supposed to work and I figured I'd mention it here in case
it's obvious to someone else...

[1] https://cirrus-ci.com/task/5546921619095552



Re: Broken make dependency somewhere near win32ver.o?

From
Andres Freund
Date:
Hi,

On 2022-03-22 15:47:13 +1300, Thomas Munro wrote:
> Here's a strange one-off failure seen on CI[1], in the
> CompilerWarnings task where we check that mingw cross-compile works:
> 
> [10:48:29.045] time make -s -j${BUILD_JOBS} world-bin
> [10:48:38.705] x86_64-w64-mingw32-gcc: error: win32ver.o: No such file
> or directory
> [10:48:38.705] make[3]: *** [Makefile:44: pg_dumpall] Error 1
> [10:48:38.705] make[3]: *** Waiting for unfinished jobs....
> [10:48:38.709] make[2]: *** [Makefile:43: all-pg_dump-recurse] Error 2
> [10:48:38.709] make[2]: *** Waiting for unfinished jobs....
> [10:48:38.918] make[1]: *** [Makefile:42: all-bin-recurse] Error 2
> [10:48:38.918] make: *** [GNUmakefile:21: world-bin-src-recurse] Error 2
> 
> I guess this implies a dependency problem somewhere around
> src/makefiles/Makefile.win32 but I'm not familiar with how that .rc
> stuff is supposed to work and I figured I'd mention it here in case
> it's obvious to someone else...

Oh. I think I figured out how to reproduce it reliably:

make -s clean
make -j pg_dumpall -C src/bin/pg_dump/
...
x86_64-w64-mingw32-gcc: error: win32ver.o: No such file or directory


The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
which in turn is what contains the dependency on WIN32RES, which in turn
contains win32ver.o. So the build succeeds if pg_dump/restores's dependencies
are built first, but not if pg_dumpall starts to be built before that...

Seems we just need to add $(WIN32RES) to pg_dumpall: ?

Greetings,

Andres Freund



Re: Broken make dependency somewhere near win32ver.o?

From
Thomas Munro
Date:
On Tue, Mar 22, 2022 at 4:14 PM Andres Freund <andres@anarazel.de> wrote:
> The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
> which in turn is what contains the dependency on WIN32RES, which in turn
> contains win32ver.o. So the build succeeds if pg_dump/restores's dependencies
> are built first, but not if pg_dumpall starts to be built before that...
>
> Seems we just need to add $(WIN32RES) to pg_dumpall: ?

Ah, yeah, that looks right.  I don't currently have a mingw setup to
test, but clearly $(WIN32RES) is passed to $(CC) despite not being
listed as a dependency.



Re: Broken make dependency somewhere near win32ver.o?

From
Andres Freund
Date:
Hi,

On 2022-03-22 18:09:08 +1300, Thomas Munro wrote:
> On Tue, Mar 22, 2022 at 4:14 PM Andres Freund <andres@anarazel.de> wrote:
> > The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
> > which in turn is what contains the dependency on WIN32RES, which in turn
> > contains win32ver.o. So the build succeeds if pg_dump/restores's dependencies
> > are built first, but not if pg_dumpall starts to be built before that...
> >
> > Seems we just need to add $(WIN32RES) to pg_dumpall: ?
> 
> Ah, yeah, that looks right.  I don't currently have a mingw setup to
> test, but clearly $(WIN32RES) is passed to $(CC) despite not being
> listed as a dependency.

Pushed a fix for that. Ended up doing it for all branches, although I was
debating with myself about doing so.

I did a quick search and didn't find other cases of this problem.

Greetings,

Andres Freund