> Cc: Jonathan Yong <10wa...@gmail.com>, Jan Hubicka <hubi...@ucw.cz>, Nathan > Sidwell <nat...@acm.org> > Date: Fri, 01 Dec 2023 09:02:55 +0100 > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, > DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, > RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, > T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 > From: Florian Weimer via Gcc <gcc@gcc.gnu.org> > > I've received a report of a mingw build failure: > > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of > function 'fork' [-Wimplicit-function-declaration] > 185 | pid = fork (); > | ^~~~ > make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > > As far as I understand it, mingw doesn't have fork and doesn't declare > it in <unistd.h>, so it's not clear to me how this has ever worked. I > would expect a linker failure. Maybe that doesn't happen because the > object containing a reference to fork is only ever pulled in if the > application calls the intercepted fork, which doesn't happen on mingw. > > What's the best way to fix this? I expect it's going to impact other > targets (perhaps for different functions) because all of > libgcov-interface.c is built unconditionally. I don't think we run > configure for the target, so we can't simply check for a definition of > the HAVE_FORK macro.
I'm not familiar with this code, so apologies in advance if what I suggest below makes no sense. If the code which calls 'fork' is never expected to be called in the MinGW build, then one way of handling this is to define a version of 'fork' that always fails, conditioned by a suitable #ifdef, so that its declaration and definition are visible when this file is compiled.
