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 DFC893858C53 for ; Sat, 26 Aug 2023 05:50:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFC893858C53 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 37Q5oT7B093110 for ; Fri, 25 Aug 2023 22:50:29 -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 smtpd8vCsZb; Fri Aug 25 22:50:25 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: Date: Fri, 25 Aug 2023 22:50:25 -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=-3.1 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=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: 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: make[3]: Entering directory '/usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/build' CC lib/exclude.o CC lib/exitfail.o CC lib/fadvise.o CC lib/creat-safer.o In file included from /usr/include/sys/signal.h:23, from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:81, from ./lib/stdlib.h:100, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:58, from /usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31: /usr/include/cygwin/signal.h:121:3: error: unknown type name 'pthread_attr_t' 121 | pthread_attr_t *sigev_notify_attributes; /* notification attributes */ | ^~~~~~~~~~~~~~ In file included from /usr/include/signal.h:6, from ./lib/signal.h:52, from /usr/include/time.h:158, from ./lib/time.h:47, from ./lib/sys/stat.h:44, from ./lib/fcntl.h:64, from ./lib/unistd.h:81, from ./lib/stdlib.h:100, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:58, from /usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31: /usr/include/sys/signal.h:227:29: error: expected ')' before 'int' 227 | int pthread_kill (pthread_t, int); | ^~~~ | ) In file included from /usr/include/sys/stat.h:22, from ./lib/sys/stat.h:47, from ./lib/fcntl.h:64, from ./lib/unistd.h:81, from ./lib/stdlib.h:100, from /usr/include/sys/cpuset.h:12, from /usr/include/sys/_pthreadtypes.h:12, from /usr/include/sys/types.h:221, from ./lib/sys/types.h:39, from ./lib/stdio.h:58, from /usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31: /usr/include/cygwin/stat.h:27:3: error: unknown type name 'timestruc_t' 27 | timestruc_t st_atim; | ^~~~~~~~~~~ /usr/include/cygwin/stat.h:28:3: error: unknown type name 'timestruc_t' 28 | timestruc_t st_mtim; | ^~~~~~~~~~~ /usr/include/cygwin/stat.h:29:3: error: unknown type name 'timestruc_t' 29 | timestruc_t st_ctim; | ^~~~~~~~~~~ /usr/include/cygwin/stat.h:32:3: error: unknown type name 'timestruc_t' 32 | timestruc_t st_birthtim; | ^~~~~~~~~~~ I've trimmed the errors back to just those from compiling lib/exclude.c. This is new breakage in 3.4.8 (per Denis) and corresponds to the new in 3.4.8 #includes added to /usr/include/sys/cpuset.h. I guess it's the include search order that has ./lib/stdlib.h being included from sys/cpuset.h rather than the "" coded there. 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 ;-). ..mark