On Fri, 1 Dec 2023, Richard Biener via Gcc wrote:

> On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Richard Biener:
> >
> > > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
> > >>
> > >> 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.
> > >
> > > This is wrapped inside
> > >
> > > #ifdef L_gcov_fork
> > > #endif
> > >
> > > grepping didn't find me what defines this, but it suggests the solution
> > > lies there ...
> >
> > That's just the general libgcc/ coding style, which puts multiple
> > related functions into one C source file.  The file is compiled multiple
> > times with different -D options using Makefile rules like this one:
> >
> > $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
> >         $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c
> >
> > It looks like this is done to emulate -Wl,--gc-sections without separate
> > source files.  Unfortunately, this is all built unconditionally.
> 
> Hmm, so why's it then referenced and not "GCed"?

On MinGW the corresponding .o file is not unpacked by the linker from libgcov.a
when fork is not referenced, so it used to work fine. The problem is that now
building the .o fails due to undeclared fork.

> The classical "solution" is to make the reference weak via sth like
> 
> extern typeof(fork) fork () __attribute__((weak));

This won't help here since fork is undeclared. Using __builtin_fork, as
mentioned in adjacent sub-thread, should work.

Alexander