From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 1EE583858D28 for ; Wed, 30 Aug 2023 05:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1EE583858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 37U5aCgH040392 for ; Tue, 29 Aug 2023 22:36:12 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 50-1-247-226.fiber.dynamic.sonic.net(50.1.247.226), claiming to be "[192.168.4.101]" via SMTP by m0.truegem.net, id smtpdEMa0Rc; Tue Aug 29 22:36:03 2023 Subject: Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8 To: cygwin@cygwin.com References: <83C27059-CB24-48F5-AC91-AB0622DF82CD@Denis-Excoffier.org> From: Mark Geisert Message-ID: <09b77b09-ea43-15b3-1552-c924d502d2f9@maxrnd.com> Date: Tue, 29 Aug 2023 22:36:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Corinna Vinschen via Cygwin wrote: > On Aug 25 22:50, Mark Geisert via Cygwin wrote: >> Hi Corinna, >> >> Corinna Vinschen via Cygwin wrote: >>> On Aug 24 14:39, Mark Geisert via Cygwin wrote: >>>> Denis Excoffier via Cygwin wrote: >>>>> Hello, >>>>> When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following error messages (see below). >>>>> There seems to be a kind of loop in the hierarchy of #includes. >>>>> Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove the 2 #includes from /usr/include/sys/cpuset.h, >>>>> this is also ok. >>>>> >>>>> Regards, >>>>> >>>>> Denis Excoffier. >>>>> >> [...compilation log excerpt elided here...] >>> >>> Usually it's easily fixable. There's typically no loop because >>> of the guards, e.g. >>> >>> #ifndef _SYS_CPUSET_H_ >>> #define _SYS_CPUSET_H_ >>> >>> but some guarding can have side effects. >>> >>> However, somebody needs to come up *at least* with a simple reproducer. >> >> It can be reproduced by running 'cygport coreutils.cygport build' in a >> prep'd coreutils source directory e.g. /usr/src/coreutils-9.0-1.src . >> Excerpt follows: > > This is not what I meant. A simple reproducer is ideally a piece of > C code which shows ;the problem with a minimum of code. In this case, > a pice of C code with the #includes required to reproduce the compiler > failing is what I'm looking for. > >> I guess it's the include search order that has ./lib/stdlib.h being included >> from sys/cpuset.h rather than the "" coded there. > > That should break including any other header file, too, which includes > . Why does it only break sys/cpuset.h? > >> I'm not familiar with building coreutils. But it seems something about the >> new #includes added to sys/cpuset.h have upset coreutils' build magic. My >> offer to replace the two problematic #includes with two explicit extern >> statements still stands ;-). > > Sorry, but this is not the right thing to do to fix such an issue. Agreed. Also, given the locus of this issue, coding an STC is problematic. I'm taking this coreutils build issue to the cygwin-apps ML for further discussion. ..mark