Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
- (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
[...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+ (void) memset (set, 0, siz);
+}
+
} /* extern C */
Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:
I attached a matching patch. Please give it a try.
I like where this discussion is going. Going to need another day to test..
..mark
Re: The correct manner to obsolete subpackage.
On Wed, 30 Aug 2023 10:59:30 -0600 Brian Inglis wrote: > On 2023-08-29 16:40, Takashi Yano via Cygwin-apps wrote: > > If the main package no longer provides a sub package, > > what is the correct manner to obsolete it? > > OBSOLETES=sub_pkg > > or > > pkg_OBSOLETES="sub_pkg1 sub_pkg2 ..." This seems to work for me as expected. Thanks! -- Takashi Yano
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:
> On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
> > On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> > > On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> > > > #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > > > -static __inline void
> > > > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > -{
> > > > - (void) memset (set, 0, siz);
> > > > -}
> > > > +void __cpuset_zero_s (size_t, cpu_set_t *);
> > > > [...]
> > > > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > +{
> > > > + (void) memset (set, 0, siz);
> > > > +}
> > > > +
> > > > } /* extern C */
> > >
> > > Also, we can avoid an external __cpuset_zero_s function by just using a
> > > loop, kind of like this:
> >
> > I attached a matching patch. Please give it a try.
>
> Shouldn't cpuset.h #include for size_t and for pid_t?
It shouldn't need that. sys/cpuset.h is a non-standard header which is
only included indirectly via sys/types.h.
We may want to change from size_t to __size_t and from pid_t to __pid_t.
That should eliminate any further dependency.
Corinna
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
- (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
[...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+ (void) memset (set, 0, siz);
+}
+
} /* extern C */
Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:
I attached a matching patch. Please give it a try.
Shouldn't cpuset.h #include for size_t and for pid_t?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [ITA] jq
On 2023-08-30 06:46, Jon Turney via Cygwin-apps wrote: On 29/08/2023 15:26, Andrew Schulman via Cygwin-apps wrote: I'd like to adopt the jq package. It's currently orphaned from Yaakov. I have an updated build script ready to push up for the current release (1.6-1), and a new release (1.7) is expected soon. Andrew I think Brian was looking at jq, so perhaps he can chime in. Thanks Jon, Okay by me - Andrew asked first - I was still looking into the check shtest crash in 1.6 and 1.7 rcs from: bash $ jq -b -cen --seq '[inputs] == []' <<< 1 and not getting to a definitive cause yet. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: The correct manner to obsolete subpackage.
On 2023-08-29 16:40, Takashi Yano via Cygwin-apps wrote: If the main package no longer provides a sub package, what is the correct manner to obsolete it? OBSOLETES=sub_pkg or pkg_OBSOLETES="sub_pkg1 sub_pkg2 ..." Creating empty sub package with sub_package_CATEGORY="_obsolete" is correct? That's more appropriate for a rename/replace e.g. old_pkg_CATEGORY=_obsolete old_pkg_SUMMARY="obsolete name for libpkg-devel" old_pkg_CONTENTS= # empty old_pkg_REQUIRES=libpkg-devel Or just deleting the sub package? How would you do that? Not producing it leaves the old release around. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: The correct manner to obsolete subpackage.
Takashi Yano via Cygwin-apps writes: > But, my case is > >> If the package is really being removed without any replacement, there >> are mechanisms to deal with that case, but that case should be really rare. > > this. pulseaudio package no longer provides esound and gconf, > however, these packages are exist in current pulseaudio package. > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a10d836640 > > The these old package is not compatible with new pulseaudio, so > these should be going to uninstall. The correct solution would be declare whatever provides suitable functionality as a replacement package, even if it doesn't provide the exact same commands, IMHO. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust
William Hu via Cygwin-apps writes: > Just checked the file and I agree that CFLAGS looks a little funny - are > there any > other stupid flags/variables that you had in mind? NOt immediately, but it makes me wonder if there's other such leakage. I have not found a (text) file that stores this information in the installed package, so it seems that the information is compiled in someplace. > Re Opam switches: As far as I understand, switches are like "git branch" but > for > different compiler installations instead of different code branches; for > example > you can install ocaml 4.14.0 and 4.12.0 side by side and switch between them > easily. In addition to some other things, it effectively edits your PATH > environment variable so when you type "ocamlc" it'll execute the appropriate > version. Yes, I know that. The complete mystery is why you can't use opam to provide results that can be packaged. > General comment: I don't know much about LLVM, but is there a reason why the > other software (dune, ocamlbuild, etc.) must be installed with the system and > not with opam? Because the expecation is that you can get everything in to a working state just by installing the packages. >> Cygport package changes are in the Cygwin Packages Git repository in the >> respective playground branch as before. > > Re OCaml cygport playground: Thanks for the cygport cleanup and changes. > A couple questions: > > src_compile: > 1. Adding flambda to a default system installation of OCaml can slow down > compile times and produce linking incompatibilities with non-flambda code > [1]. > Additionally, there may be value in a vanilla out-of-the-box OCaml > distribution. I've mainly includeed it because LLVM complained it wasn't enabled (obviously it can build the OCaml bindings with and without flambda) since it seems to work and test OK I just flipped that switch. > Let me know if there is some general Cygwin guidance on what features > packaged > language compilers should support. Otherwise, if flambda is necessary for > LLVM, > I could package an flambda and a non-flambda release for each version, and > the > user can pick which one they prefer. I don't think that makes any sense given the way the packaging is done at the moment. In fact, ever since you updated to 4.14.0 all other OCaml packages in Cygwin were dead since you didn't update these at the same time and there is no mechanism in place yet to ensure that ocaml-* packages and the ocaml package target the same version of the compiler. > 2. What benefit does splitting "cygmake" into the 3-step "cygmake world, opt, > opt.opt" have? Plain old "make/cygmake" with no target appears to be the > recommended compilation step. Hysterical raisins… before I got things to actually build it would stop in various places and I was tring to find out where that happened. I've not gone back to reduce it again since it doewsn't incur any (or at least not noticeable) overhead at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: The correct manner to obsolete subpackage.
Hi Jon, Thanks the answer. On Wed, 30 Aug 2023 13:43:15 +0100 Jon Turney wrote: > On 29/08/2023 23:40, Takashi Yano via Cygwin-apps wrote: > > If the main package no longer provides a sub package, > > what is the correct manner to osolete it? > > > > Creating empty sub package with > > sub_package_CATEGORY="_obsolete" > > is correct? > > To answer the question correctly, I need to know what you want to happen > for people who have the subpackage installed currently. > > If the package is replaced or superseded by a different package (so > sub_package should get uninstalled, and replacement_package installed > instead), just write: > > replacement_package_OBSOLETES="sub_package" Yeah, I found this in some packages. But, my case is > If the package is really being removed without any replacement, there > are mechanisms to deal with that case, but that case should be really rare. this. pulseaudio package no longer provides esound and gconf, however, these packages are exist in current pulseaudio package. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a10d836640 The these old package is not compatible with new pulseaudio, so these should be going to uninstall. -- Takashi Yano
Re: [ITA] jq
On 29/08/2023 15:26, Andrew Schulman via Cygwin-apps wrote: I'd like to adopt the jq package. It's currently orphaned from Yaakov. I have an updated build script ready to push up for the current release (1.6-1), and a new release (1.7) is expected soon. Andrew Thanks. I think Brian was looking at jq, so perhaps he can chime in.
Re: The correct manner to obsolete subpackage.
On 29/08/2023 23:40, Takashi Yano via Cygwin-apps wrote: If the main package no longer provides a sub package, what is the correct manner to osolete it? Creating empty sub package with sub_package_CATEGORY="_obsolete" is correct? To answer the question correctly, I need to know what you want to happen for people who have the subpackage installed currently. If the package is replaced or superseded by a different package (so sub_package should get uninstalled, and replacement_package installed instead), just write: replacement_package_OBSOLETES="sub_package" If the package is really being removed without any replacement, there are mechanisms to deal with that case, but that case should be really rare. Or just deleting the sub package? Generally, you never want to do this, at it means the current version will linger, remaining installed (potentially with (currently unreported) file conflicts with any replacement).
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> > #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > -static __inline void
> > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > -{
> > - (void) memset (set, 0, siz);
> > -}
> > +void __cpuset_zero_s (size_t, cpu_set_t *);
> > [...]
> > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > +{
> > + (void) memset (set, 0, siz);
> > +}
> > +
> > } /* extern C */
>
> Also, we can avoid an external __cpuset_zero_s function by just using a
> loop, kind of like this:
I attached a matching patch. Please give it a try.
Thanks,
Corinna
>From a8b26a78ae600f471f54769c28b6d3542aabab06 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Wed, 30 Aug 2023 11:32:02 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: add cpuset-specific external functions
The latest incarnation of sys/cpuset.h broke building coreutils.
The reason is the inclusion of stdlib.h and string.h and hence
premature requests for datatypes not yet defined in the include
chain.
Avoid this by defining __cpuset_alloc and __cpuset_free as external
functions, now defined in sched.cc. Linux is doing this too, just
using different names for the functions. Redefine __cpuset_zero_s
to use __builtin_memset only on compilers supporting it, otherwise
using a simple loop. Drop the stdlib.h and string.h includes.
Fixes: 3f2790e04439 ("Cygwin: Make gcc-specific code in
compiler-agnostic")
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/cygwin.din | 2 ++
winsup/cygwin/include/sys/cpuset.h | 25 +++--
winsup/cygwin/sched.cc | 12
3 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/winsup/cygwin/cygwin.din b/winsup/cygwin/cygwin.din
index ee646fddc862..3afadb7f3a77 100644
--- a/winsup/cygwin/cygwin.din
+++ b/winsup/cygwin/cygwin.din
@@ -49,6 +49,8 @@ __b64_ntop NOSIGFE
__b64_pton NOSIGFE
__bsd_qsort_r NOSIGFE
__chk_fail SIGFE
+__cpuset_alloc SIGFE
+__cpuset_free SIGFE
__cxa_atexit = cygwin__cxa_atexit SIGFE
__cxa_finalize SIGFE
__dn_comp SIGFE
diff --git a/winsup/cygwin/include/sys/cpuset.h
b/winsup/cygwin/include/sys/cpuset.h
index 95c777cfbc6d..2ab2b95f0d65 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,8 +9,7 @@ details. */
#ifndef _SYS_CPUSET_H_
#define _SYS_CPUSET_H_
-#include
-#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -42,25 +41,23 @@ __cpuset_alloc_size (int num)
}
#define CPU_ALLOC(num) __cpuset_alloc (num)
-static __inline cpu_set_t *
-__cpuset_alloc (int num)
-{
- return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
-}
+extern cpu_set_t * __cpuset_alloc (int);
#define CPU_FREE(set) __cpuset_free (set)
-static __inline void
-__cpuset_free (cpu_set_t *set)
-{
- free (set);
-}
+void __cpuset_free (cpu_set_t *);
/* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
+static __inline
__cpuset_zero_s (size_t siz, cpu_set_t *set)
{
- (void) memset (set, 0, siz);
+#if __GNUC_PREREQ (2, 91)
+ __builtin_memset (set, 0, siz);
+#else
+ siz /= sizeof (__cpu_mask);
+ while (siz > 0)
+set->_bits[--siz] = 0;
+#endif
}
#define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
diff --git a/winsup/cygwin/sched.cc b/winsup/cygwin/sched.cc
index d7bad852765c..845fcef5702c 100644
--- a/winsup/cygwin/sched.cc
+++ b/winsup/cygwin/sched.cc
@@ -684,4 +684,16 @@ done:
return 0;
}
+cpu_set_t *
+__cpuset_alloc (int num)
+{
+ return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
+}
+
+void
+__cpuset_free (cpu_set_t *set)
+{
+ free (set);
+}
+
} /* extern C */
--
2.41.0
Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust
On Tuesday, August 29th, 2023 at 10:18 PM, William Hu wrote: > src_test: > 1. I believe "make ocamltest" does not run the testsuite; AFAIU, it builds the > auxiliary testing software instead. So far the only ways I know of to run the > testsuite are either "make tests" or cd'ing into the testsuite directory and > running "make all" (the old method). Apologies, ignore my previous comment about src_test - I missed the final "cygmake tests" line! Now I'm simply curious what splitting the testsuite build step into three make calls does.
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> -static __inline void
> -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> -{
> - (void) memset (set, 0, siz);
> -}
> +void __cpuset_zero_s (size_t, cpu_set_t *);
> [...]
> +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> +{
> + (void) memset (set, 0, siz);
> +}
> +
> } /* extern C */
Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
static __inline
__cpuset_zero_s (size_t siz, cpu_set_t *set)
{
#if __GNUC_PREREQ (2, 91)
__builtin_memset (set, 0, siz);
#else
siz /= sizeof (__cpu_mask);
while (siz > 0)
set->_bits[--siz] = 0;
#endif
}
Corinna
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Hi Mark,
On Aug 30 00:29, Mark Geisert via Cygwin-apps wrote:
> [redirected from the main Cygwin ML]
> Corinna Vinschen via Cygwin wrote:
> > 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.
> [...]
> 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 have another solution, based on how Linux does it, see the attached patch.
What do you think? If that's ok with you, I'll push it.
Thanks,
Corinna
>From 6cb039fdefb30522795861c47f3f1facf7d70eb2 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Wed, 30 Aug 2023 11:32:02 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: add cpuset-specific external functions
The latest incarnation of sys/cpuset.h broke building coreutils.
The reason is the inclusion of stdlib.h and string.h and hence
premature requests for datatypes not yet defined in the include
chain.
Avoid this by defining __cpuset_alloc, __cpuset_free, and
__cpuset_zero_s as external functions, now defined in sched.cc.
Linux is doing this too, just using different names for the
functions. Drop the includes entirely.
Fixes: 3f2790e04439 ("Cygwin: Make gcc-specific code in
compiler-agnostic")
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/cygwin.din | 3 +++
winsup/cygwin/include/sys/cpuset.h | 21 +++--
winsup/cygwin/sched.cc | 18 ++
3 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/winsup/cygwin/cygwin.din b/winsup/cygwin/cygwin.din
index ee646fddc862..1fb7a880f9fb 100644
--- a/winsup/cygwin/cygwin.din
+++ b/winsup/cygwin/cygwin.din
@@ -49,6 +49,9 @@ __b64_ntop NOSIGFE
__b64_pton NOSIGFE
__bsd_qsort_r NOSIGFE
__chk_fail SIGFE
+__cpuset_alloc SIGFE
+__cpuset_free SIGFE
+__cpuset_zero_s SIGFE
__cxa_atexit = cygwin__cxa_atexit SIGFE
__cxa_finalize SIGFE
__dn_comp SIGFE
diff --git a/winsup/cygwin/include/sys/cpuset.h
b/winsup/cygwin/include/sys/cpuset.h
index 95c777cfbc6d..371432931b48 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,9 +9,6 @@ details. */
#ifndef _SYS_CPUSET_H_
#define _SYS_CPUSET_H_
-#include
-#include
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -42,26 +39,14 @@ __cpuset_alloc_size (int num)
}
#define CPU_ALLOC(num) __cpuset_alloc (num)
-static __inline cpu_set_t *
-__cpuset_alloc (int num)
-{
- return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
-}
+extern cpu_set_t * __cpuset_alloc (int);
#define CPU_FREE(set) __cpuset_free (set)
-static __inline void
-__cpuset_free (cpu_set_t *set)
-{
- free (set);
-}
+void __cpuset_free (cpu_set_t *);
/* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
- (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
#define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
static __inline void
diff --git a/winsup/cygwin/sched.cc b/winsup/cygwin/sched.cc
index d7bad852765c..7e2d1cf783af 100644
--- a/winsup/cygwin/sched.cc
+++ b/winsup/cygwin/sched.cc
@@ -684,4 +684,22 @@ done:
return 0;
}
+cpu_set_t *
+__cpuset_alloc (int num)
+{
+ return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
+}
+
+void
+__cpuset_free (cpu_set_t *set)
+{
+ free (set);
+}
+
+void
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+ (void) memset (set, 0, siz);
+}
+
} /* extern C */
--
2.41.0
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
[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
