Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert]

[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

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

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 <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 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

[-- Attachment #2: 0001-Cygwin-sys-cpuset.h-add-cpuset-specific-external-fun.patch --]
[-- Type: text/plain, Size: 3088 bytes --]

From 6cb039fdefb30522795861c47f3f1facf7d70eb2 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
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 <sys/cpuset.h> compiler-agnostic")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 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 <stdlib.h>
-#include <string.h>
-
 #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

[Corinna Vinschen]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

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

[-- Attachment #2: 0001-Cygwin-sys-cpuset.h-add-cpuset-specific-external-fun.patch --]
[-- Type: text/plain, Size: 3203 bytes --]

From a8b26a78ae600f471f54769c28b6d3542aabab06 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
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 <sys/cpuset.h> compiler-agnostic")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 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 <stdlib.h>
-#include <string.h>
+#include <sys/features.h>
 
 #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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Brian Inglis]

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 <stddef.h> for size_t and <sys/types.h> 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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen]

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 <stddef.h> for size_t and <sys/types.h> 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

[Mark Geisert]

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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
> 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 <stddef.h> for size_t and <sys/types.h> 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.

Try this:


[-- Attachment #2: 0001-Cygwin-sys-cpuset.h-use-internal-base-types.patch --]
[-- Type: text/plain, Size: 4852 bytes --]

From ecc6012b90ba226c7ce92d4d0a12e6b4824ee03a Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
Date: Wed, 30 Aug 2023 21:11:42 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: use internal base types

Use __size_t and __pid_t instead of size_t and pid_t to avoid
further dependencies to external headers.

Reported-by: Brian Inglis <Brian.Inglis@Shaw.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 winsup/cygwin/include/sys/cpuset.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h b/winsup/cygwin/include/sys/cpuset.h
index 2ab2b95f0d65..a5a8fa81ef3d 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -29,15 +29,15 @@ typedef struct
 } cpu_set_t;
 
 #if __GNU_VISIBLE
-int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
+int __sched_getaffinity_sys (__pid_t, __size_t, cpu_set_t *);
 
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
    Allocations are padded such that full-word operations can be done easily. */
 #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
-static __inline size_t
+static __inline __size_t
 __cpuset_alloc_size (int num)
 {
-  return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof (__cpu_mask));
+  return (__size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof (__cpu_mask));
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
@@ -49,7 +49,7 @@ 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
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
+__cpuset_zero_s (__size_t siz, cpu_set_t *set)
 {
 #if __GNUC_PREREQ (2, 91)
   __builtin_memset (set, 0, siz);
@@ -62,7 +62,7 @@ __cpuset_zero_s (size_t siz, cpu_set_t *set)
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
 static __inline void
-__cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_set_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
     (set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
@@ -70,7 +70,7 @@ __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
 static __inline void
-__cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_clr_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
     (set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
@@ -78,7 +78,7 @@ __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
 static __inline int
-__cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_isset_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   int res = 0;
   if (cpu >= 0 && cpu < 8 * siz)
@@ -88,7 +88,7 @@ __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
 static __inline int
-__cpuset_count_s (size_t siz, cpu_set_t *set)
+__cpuset_count_s (__size_t siz, cpu_set_t *set)
 {
   int i, res = 0;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
@@ -98,7 +98,7 @@ __cpuset_count_s (size_t siz, cpu_set_t *set)
 
 #define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
 static __inline void
-__cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+__cpuset_and_s (__size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
   int i;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
@@ -107,7 +107,7 @@ __cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 
 #define CPU_OR_S(siz, dst, src1, src2) __cpuset_or_s (siz, dst, src1, src2)
 static __inline void
-__cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+__cpuset_or_s (__size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
   int i;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
@@ -116,7 +116,7 @@ __cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 
 #define CPU_XOR_S(siz, dst, src1, src2) __cpuset_xor_s (siz, dst, src1, src2)
 static __inline void
-__cpuset_xor_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+__cpuset_xor_s (__size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
   int i;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
@@ -125,7 +125,7 @@ __cpuset_xor_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 
 #define CPU_EQUAL_S(siz, src1, src2) __cpuset_equal_s (siz, src1, src2)
 static __inline int
-__cpuset_equal_s (size_t siz, cpu_set_t *src1, cpu_set_t *src2)
+__cpuset_equal_s (__size_t siz, cpu_set_t *src1, cpu_set_t *src2)
 {
   int i, res = 1;
   for (i = 0; res && i < siz / sizeof (__cpu_mask); i++)
-- 
2.41.0

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert]

Hi Corinna,

Corinna Vinschen via Cygwin-apps wrote:
> On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
>> 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 <stddef.h> for size_t and <sys/types.h> 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.
> 
> Try this:

After applying both patches to my system I was able to build coreutils without 
issues.  After updating my local Cygwin tree's sched.cc and cygwin.din I rebuilt 
the Cygwin DLL without issues.

I then tried recompiling a CPU affinity test program of mine (that uses cpusets) 
but it could not link due to missing __cpuset_alloc and __cpuset_free.  I think 
this is likely a local issue of mine in copying newly-built stuff into place, 
though I've automated that process and do it frequently, so...  ?

I believe those two patches you wrote are fine.  Ship when convenient, I say.
Cheers & Regards,

..mark

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen]

On Sep  1 03:28, Mark Geisert via Cygwin-apps wrote:
> Hi Corinna,
> 
> Corinna Vinschen via Cygwin-apps wrote:
> > On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
> > > 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 <stddef.h> for size_t and <sys/types.h> 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.
> > 
> > Try this:
> 
> After applying both patches to my system I was able to build coreutils
> without issues.  After updating my local Cygwin tree's sched.cc and
> cygwin.din I rebuilt the Cygwin DLL without issues.
> 
> I then tried recompiling a CPU affinity test program of mine (that uses
> cpusets) but it could not link due to missing __cpuset_alloc and
> __cpuset_free.  I think this is likely a local issue of mine in copying
> newly-built stuff into place, though I've automated that process and do it
> frequently, so...  ?

You missed to copy libcygwin.a to /usr/lib.

> I believe those two patches you wrote are fine.  Ship when convenient, I say.
> Cheers & Regards,

Great, thanks for testing!


Corinna

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert]

Corinna Vinschen via Cygwin-apps wrote:
> On Sep  1 03:28, Mark Geisert via Cygwin-apps wrote:
>> I then tried recompiling a CPU affinity test program of mine (that uses
>> cpusets) but it could not link due to missing __cpuset_alloc and
>> __cpuset_free.  I think this is likely a local issue of mine in copying
>> newly-built stuff into place, though I've automated that process and do it
>> frequently, so...  ?
> 
> You missed to copy libcygwin.a to /usr/lib.

That's what I thought at first as well.  However nm showed the __cpuset_* 
functions present in the newly-created libcygwin.a.  Did I mis-copy the new lib 
somewhere incorrect?  Nope.  It turned out I had stale files in 
/usr/x86_64-pc-cygwin/lib that's evidently earlier in the link search path than 
the directory with newest contents.

I just renamed that directory out of the way and now the test program links and 
runs without issues.  I should investigate what populated that directory though.

I saw that you've applied your two patches.  Excellent!

..mark