Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Florian Weimer <fweimer@redhat.com>]

* 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.

Thanks,
Florian