On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer <fwei...@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"?

The classical "solution" is to make the reference weak via sth like

extern typeof(fork) fork () __attribute__((weak));

Richard.

> Thanks,
> Florian
>

Reply via email to