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
