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 D6E8E3858C53 for ; Wed, 30 Aug 2023 07:29:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D6E8E3858C53 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 37U7Tngl052774 for ; Wed, 30 Aug 2023 00:29:49 -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 smtpd8jbQwM; Wed Aug 30 00:29:41 2023 Subject: Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8 To: Cygwin-Apps References: <83C27059-CB24-48F5-AC91-AB0622DF82CD@Denis-Excoffier.org> From: Mark Geisert Message-ID: <603386c9-d4a0-82cd-a8e4-02f298f9047b@maxrnd.com> Date: Wed, 30 Aug 2023 00:29:41 -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: [redirected from the main Cygwin ML] Hi Corinna, 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. It is not a loop. >>>>> Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i removethe 2 #includes from /usr/include/sys/cpuset.h, >>>>> this is also ok. This is an important clue. >>>>> >>>>> 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've always been supportive of the notion of STCs, but for this issue it would mean duplicating a bunch of coreutils-build-built include files (in its lib directory) and I decided, why not just cut the coreutils build process back to the first compilation that exhibits the error? So I modified coreutils.cygport to change "cygmake" to "cygmake --trace" and ran 'cygport build' to see all gcc commands as they're executed. I then extracted the gcc command that compiles chroot.c to a new STC shell script where I could modify gcc options at will. I changed "-c" to "-E" to see the sequence of include file usage and where #defines actually happen. From this I discovered that pthread_attr_t and pthread_t defs are missing because sys/_pthreadtypes.h includes sys/cpuset.h which starts a whole include chain ending up in sys/signal.h where the defs are needed. Note they are defined in sys/_pthreadtypes.h where we started, but haven't been seen yet because sys/cpuset.h has gone off on this detour. Similarly, the timestruc_t def is missing because sys/_pthreadtypes.h again starts an include chain that ends up in sys/stat.h where the def is needed. Note timestruc_t is defined in machine/types.h, which is included (by sys/types.h) after sys/_pthreadtypes.h, so the def hasn't been seen yet because of a similar detour. The fix I'm considering is to (1) move sys/_pthreadtypes.h's "#include sys/cpuset.h" to just before its final #endif, and (2) exchange the positions of "#include " and "#include " within sys/types.h. I could submit for review a patch to do these things. An alternative would be to somehow massage the coreutils build include-file-wrapping to accomplish the same end. I personally don't have the time or skills to figure that out. I hope this info is usable in one form or another. Regards, ..mark