From: Mark Geisert <mark@maxrnd.com>
To: Cygwin-Apps <cygwin-apps@cygwin.com>
Subject: Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Date: Wed, 30 Aug 2023 00:29:41 -0700 [thread overview]
Message-ID: <603386c9-d4a0-82cd-a8e4-02f298f9047b@maxrnd.com> (raw)
In-Reply-To: <ZOoFxp0yvqK3ZWxX@calimero.vinschen.de>
[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 <sys/_pthreadtypes.h>" and "#include
<machine/types.h>" 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
next parent reply other threads:[~2023-08-30 7:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <83C27059-CB24-48F5-AC91-AB0622DF82CD@Denis-Excoffier.org>
[not found] ` <aa38a12e-875a-bfaf-6427-2f8d05c0bc47@maxrnd.com>
[not found] ` <ZOh2lNSnYAJmZqUh@calimero.vinschen.de>
[not found] ` <ff004ecd-0bd7-1886-bf81-88daa6b48f2a@maxrnd.com>
[not found] ` <ZOoFxp0yvqK3ZWxX@calimero.vinschen.de>
2023-08-30 7:29 ` Mark Geisert [this message]
2023-08-30 9:34 ` Corinna Vinschen
2023-08-30 9:57 ` Corinna Vinschen
2023-08-30 12:17 ` Corinna Vinschen
2023-08-30 18:04 ` Brian Inglis
2023-08-30 18:10 ` Corinna Vinschen
2023-08-31 8:24 ` Corinna Vinschen
2023-09-01 10:28 ` Mark Geisert
2023-09-01 10:38 ` Corinna Vinschen
2023-09-02 6:51 ` Mark Geisert
2023-08-31 6:54 ` Mark Geisert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=603386c9-d4a0-82cd-a8e4-02f298f9047b@maxrnd.com \
--to=mark@maxrnd.com \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).