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

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

[Julian Waters]

What about removing the _gcov_fork object file from the list of object
files in Makefile.in (Named LIBGCOV_INTERFACE last I remember) if the
target doesn't support fork? Seems cleaner in my opinion.

best regards,
Julian

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

[Florian Weimer]

* LIU Hao via Gcc:

> 在 2023/12/8 21:59, Florian Weimer via Gcc 写道:
>>    [PATCH] libgcov: Call __builtin_fork instead of fork
>>    <https://inbox.sourceware.org/gcc-patches/87edg4epw5.fsf@oldenburg.str.redhat.com/>
>
> May I ask why it's not something like this?
>
> Even though there may be people who define `fork()` in global scope, it will be semantically 
> different from the POSIX fork.
>
> ```
> diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
> index b2ee9308641..10ce8edc4fb 100644
> --- a/libgcc/libgcov-interface.c
> +++ b/libgcc/libgcov-interface.c
> @@ -174,7 +174,7 @@ __gcov_dump (void)
>
>   #endif /* L_gcov_dump */
>
> -#ifdef L_gcov_fork
> +#if defined L_gcov_fork && !defined _WIN32
>   /* A wrapper for the fork function.  We reset counters in the child
>      so that they are not counted twice.  */
>
> ```

Other systems probably have the same issue.  We just don't have an
autobuilder, or we have one and I haven't seen its error.

Thanks,
Florian

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

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 861 bytes --]

在 2023/12/8 21:59, Florian Weimer via Gcc 写道:
>    [PATCH] libgcov: Call __builtin_fork instead of fork
>    <https://inbox.sourceware.org/gcc-patches/87edg4epw5.fsf@oldenburg.str.redhat.com/>

May I ask why it's not something like this?

Even though there may be people who define `fork()` in global scope, it will be semantically 
different from the POSIX fork.


```
diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
index b2ee9308641..10ce8edc4fb 100644
--- a/libgcc/libgcov-interface.c
+++ b/libgcc/libgcov-interface.c
@@ -174,7 +174,7 @@ __gcov_dump (void)

  #endif /* L_gcov_dump */

-#ifdef L_gcov_fork
+#if defined L_gcov_fork && !defined _WIN32
  /* A wrapper for the fork function.  We reset counters in the child
     so that they are not counted twice.  */

```


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Florian Weimer]

* Mark Wielaard:

> BTW. The gcc-fedora-mingw buildbot has been broken because of this
> issue for the last week:
>
> https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw
> ../../../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:935: _gcov_fork.o] Error 1

Yes, that's why I submitted a patch:

  [PATCH] libgcov: Call __builtin_fork instead of fork
  <https://inbox.sourceware.org/gcc-patches/87edg4epw5.fsf@oldenburg.str.redhat.com/>

Thanks,
Florian

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

[Julian Waters]

I think the most reasonable thing to do is to remove _gcov_fork from
LIBGCOV_INTERFACE in libgcc's Makefile.in when the target is Windows.

best regards,
Julian

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

[Mark Wielaard]

Hi,

On Fri, 2023-12-01 at 13:09 +0100, Jakub Jelinek via Gcc wrote:
> On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > > On Dez 01 2023, Richard Biener via Gcc wrote:
> > > 
> > > > Hmm, so why's it then referenced and not "GCed"?
> > > 
> > > This has nothing to do with garbage collection.  It's just the way
> > > libgcc avoids having too many source files.  It would be exactly the
> > > same if every function were in its own file.
> > 
> > THe ifdef machinery makes every function to go insto its own .o file
> > which are then archived.  So if user code never calls to fork, the .o
> > file with fork wrapper should not be picked by linker and we should not
> > have link error.
> > 
> > If user code calls fork, then the .o file with wrapper should be picked
> > and we will get linker error on missing fork.  So I think it ought to
> > work as it is now.  Does mingw linker behave somehow differently with
> > archives?  Or is there problem with a libgcov being DLL or something?
> 
> The problem is that the changes to switch to modern C result in calls to
> unprototyped function being an error rather than just warning as before.
> int foo (void) { return fork (); }
> warning: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
> previously, now
> error: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
> (by default in C99+).
> 
> So, as has been discussed earlier, either we should use __builtin_fork ()
> rather than fork (), or we need in configure to test for fork prototype and
> if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled
> on targets which don't have fork prototyped.

BTW. The gcc-fedora-mingw buildbot has been broken because of this
issue for the last week:

https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw
../../../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:935: _gcov_fork.o] Error 1

Cheers,

Mark

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

[Jakub Jelinek]

On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > On Dez 01 2023, Richard Biener via Gcc wrote:
> > 
> > > Hmm, so why's it then referenced and not "GCed"?
> > 
> > This has nothing to do with garbage collection.  It's just the way
> > libgcc avoids having too many source files.  It would be exactly the
> > same if every function were in its own file.
> 
> THe ifdef machinery makes every function to go insto its own .o file
> which are then archived.  So if user code never calls to fork, the .o
> file with fork wrapper should not be picked by linker and we should not
> have link error.
> 
> If user code calls fork, then the .o file with wrapper should be picked
> and we will get linker error on missing fork.  So I think it ought to
> work as it is now.  Does mingw linker behave somehow differently with
> archives?  Or is there problem with a libgcov being DLL or something?

The problem is that the changes to switch to modern C result in calls to
unprototyped function being an error rather than just warning as before.
int foo (void) { return fork (); }
warning: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
previously, now
error: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
(by default in C99+).

So, as has been discussed earlier, either we should use __builtin_fork ()
rather than fork (), or we need in configure to test for fork prototype and
if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled
on targets which don't have fork prototyped.

	Jakub

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

[Jan Hubicka]

> On Dez 01 2023, Richard Biener via Gcc wrote:
> 
> > Hmm, so why's it then referenced and not "GCed"?
> 
> This has nothing to do with garbage collection.  It's just the way
> libgcc avoids having too many source files.  It would be exactly the
> same if every function were in its own file.

THe ifdef machinery makes every function to go insto its own .o file
which are then archived.  So if user code never calls to fork, the .o
file with fork wrapper should not be picked by linker and we should not
have link error.

If user code calls fork, then the .o file with wrapper should be picked
and we will get linker error on missing fork.  So I think it ought to
work as it is now.  Does mingw linker behave somehow differently with
archives?  Or is there problem with a libgcov being DLL or something?

Honza
> 
> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

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

[Andreas Schwab]

On Dez 01 2023, Richard Biener via Gcc wrote:

> Hmm, so why's it then referenced and not "GCed"?

This has nothing to do with garbage collection.  It's just the way
libgcc avoids having too many source files.  It would be exactly the
same if every function were in its own file.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]


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

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

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 506 bytes --]

在 2023/12/1 17:09, Richard Biener via Gcc 写道:
> 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));

There are issues about weak symbols on mingw targets. Calls to weak functions can jump to random, 
non-allocated memory and cause faults. Instead, duplicates of COMDAT sections are removed by the 
`.linkonce discard` directive.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Alexander Monakov]

On Fri, 1 Dec 2023, LIU Hao via Gcc wrote:

> >> 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 pretty sure configure runs for the target, but for musl-cross-make
it would be nice to limit it to declaration check rather than link test
(musl-cross-make installs libc headers, then configures and builds gcc
and libgcc just once, then builds libc, then builds the rest of gcc target
libraries, IIRC).

> > 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.
> 
> Makes sense. The target-specific macro `_WIN32` serves that purpose.
> 
> However `fork()` doesn't actually exist there, and linking should indeed fail.
> Maybe `__gcov_fork()` shouldn't be defined at all.

A possible stop-gap solution is using __builtin_fork() instead.

Alexander

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

[Richard Biener]

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"?

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

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

Richard.

> Thanks,
> Florian
>

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

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --]

在 2023/12/1 16:19, Eli Zaretskii via Gcc 写道:
>> 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.

That's correct. No program has been calling `fork()` in any way.


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

Makes sense. The target-specific macro `_WIN32` serves that purpose.

However `fork()` doesn't actually exist there, and linking should indeed fail. Maybe `__gcov_fork()` 
shouldn't be defined at all.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Florian Weimer]

* 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

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

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

Richard.

>
> Thanks,
> Florian
>

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

[Eli Zaretskii]

> Cc: Jonathan Yong <10walls@gmail.com>, Jan Hubicka <hubicka@ucw.cz>, Nathan
>  Sidwell <nathan@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.

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

[Florian Weimer]

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.

Thanks,
Florian