From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 470F73858C62 for ; Fri, 1 Dec 2023 08:03:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 470F73858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 470F73858C62 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701417782; cv=none; b=sfUPK48cso0Uif8fo6M7wfQiGoIPzNalNgXb+xxlV2dQodJciHW+S895XHnIdZr6ribEwWazcaqVn8gk0p4IURy2tK0qjPKiKLHhHRzsfcIDNxvi4KyU1e3sqFjK6Wlf1timkLdYbUxIBZm1PS81VTUej0TjAopdWVSTBXXCTzc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701417782; c=relaxed/simple; bh=IBPrHTRgl7HLXa2ChxenJiuug7zdhBV5KH+lSex+ULo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=C37Jnxxo9+R2Vk9eOhrrWFSPFxkbvXW7pvNPNwwTevICcraIOhlsfFjz7I6boz1LywgeUjgoqcq5VSYI3QBmZhUceGtMFh79AjvvMubsu95hGIS9XI9rCETBnC6s3hDnWjeDkVs3DDrDJJCMiympi6FEY22SxlXsv/yLykz3p7Q= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701417779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=F0lZnM6n5n5v0gZN6fL8ByYAhRupXQGRAExe2dheudM=; b=CzMuFPj7eGJvPAmDBJc6VmXc/r3grsHMoQ6bnUKdrEWMwFd89ePvkZEwu7yedXR3Vklyuy +SeqRP2vjVWr2CtrbcrXB8LUgKlXozu41KSPB2tyoYqvq+Nspt3Z5vHId3b4qOPo/7kLH7 /VBWBmJ2KCT+Logwask1hA5ZwiDsZkk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-300-M-9xjGkAOKqKjVQESYTdBA-1; Fri, 01 Dec 2023 03:02:58 -0500 X-MC-Unique: M-9xjGkAOKqKjVQESYTdBA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2DD00811E82; Fri, 1 Dec 2023 08:02:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F221310E46; Fri, 1 Dec 2023 08:02:56 +0000 (UTC) From: Florian Weimer To: gcc@gcc.gnu.org Cc: Jonathan Yong <10walls@gmail.com>, Jan Hubicka , Nathan Sidwell Subject: libgcov, fork, and mingw (and other targets without the full POSIX set) Date: Fri, 01 Dec 2023 09:02:55 +0100 Message-ID: <878r6es634.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 , 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