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
