[Bug 259787] sched.h: unknown type name 'cpu_set_t' after 160b4b922b6021848b6b48afc894d16b879b7af2

bugzilla...@freebsd.org

unread,

Nov 12, 2021, 9:41:50 PM11/12/21

to multi...@freebsd.org

bugzilla...@freebsd.org

unread,

Nov 12, 2021, 9:45:18 PM11/12/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #6 from Charlie Li <vis...@freebsd.org> ---
*** Bug 259801 has been marked as a duplicate of this bug. ***

bugzilla...@freebsd.org

unread,

Nov 12, 2021, 9:47:39 PM11/12/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #7 from tod.j...@gmail.com ---
Here's a patch for wine-devel (didn't look at other versions) if anyone is
impatient:

--- server/thread.c.orig 2021-11-05 16:14:05.000000000 -0600
+++ server/thread.c 2021-11-12 18:50:36.571110000 -0700
@@ -571,7 +571,11 @@
#ifdef HAVE_SCHED_SETAFFINITY
if (thread->unix_tid != -1)
{
+ #ifdef __FreeBSD__
+ cpuset_t set;
+ #else
cpu_set_t set;
+ #endif
int i;
affinity_t mask;

@@ -592,7 +596,11 @@
#ifdef HAVE_SCHED_SETAFFINITY
if (thread->unix_tid != -1)
{
+ #ifdef __FreeBSD__
+ cpuset_t set;
+ #else
cpu_set_t set;
+ #endif
unsigned int i;

if (!sched_getaffinity( thread->unix_tid, sizeof(set), &set ))

bugzilla...@freebsd.org

unread,

Nov 13, 2021, 3:15:32 PM11/13/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #8 from Charlie Li <vis...@freebsd.org> ---
kib@ has committed base 90fa9705d5cd29cf11c5dc7319299788dec2546a, try updating
to or past.

bugzilla...@freebsd.org

unread,

Nov 13, 2021, 3:56:12 PM11/13/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #9 from tod.j...@gmail.com ---
Can't test yet myself, but it looks like we can opt back in for example with
Ffmpeg like:

-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) && defined _WITH_CPU_SET_T

cpu_set_t cpuset;

CPU_ZERO(&cpuset);

Cool, doesn't seem too troublesome.

bugzilla...@freebsd.org

unread,

Nov 13, 2021, 5:01:43 PM11/13/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #10 from tod.j...@gmail.com ---
Well, not exactly like that. That's a bad example and shouldn't work, but I get
the idea.

Anyway, ffmpeg on 14.0-CURRENT #1 main-n250654-64ba1f4cf3a builds fine for me
now since HAVE_SCHED_GETAFFINITY isn't visible anymore.

bugzilla...@freebsd.org

unread,

Nov 14, 2021, 11:29:35 AM11/14/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #11 from Evgeniy Khramtsov <evg...@khramtsov.org> ---
14-CURRENT as of base 20aa35977 still can't build:

benchmarks/iperf3

[...]
iperf_api.c:4460:5: error: unknown type name 'cpu_set_t'; did you mean
'cpuset_t'?
cpu_set_t cpu_set;
^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

graphics/cairo

[...]
cairo-perf-micro.c:418:5: error: unknown type name 'cp
u_set_t'; did you mean 'cpusetid_t'?
cpu_set_t affinity;
^~~~~~~~~
cpusetid_t
/usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
typedef __cpusetid_t cpusetid_t;
^
cairo-perf-micro.c:421:9: error: implicit declaration of function
'sched_getaffinity' is inva
lid in C99 [-Werror,-Wimplicit-function-declaration]
if (sched_getaffinity(0, sizeof(affinity), &affinity)) {
^
cairo-perf-micro.c:426:35: error: use of undeclared identifier 'CPU_SETSIZE'
for(i = 0, cpu_count = 0; i < CPU_SETSIZE; ++i) {
^
cairo-perf-micro.c:427:6: error: implicit declaration of function 'CPU_ISSET'
is invalid in C
99 [-Werror,-Wimplicit-function-declaration]
if (CPU_ISSET(i, &affinity))
^
4 errors generated.

graphics/mesa-devel

[...]
src/util/libmesa_util.a.p/u_cpu_detect.c.o -MF
src/util/libmesa_util.a.p/u_cpu_detect.c.o.d -o
src/util/libmesa_util.a.p/u_cpu_detect.c.o -c ../src/util/u_cpu_detect.c
../src/util/u_cpu_detect.c:613:11: error: implicit declaration of function
'sched_getaffinity' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (sched_getaffinity(getpid(), sizeof(affin), &affin) == 0)
^
../src/util/u_cpu_detect.c:613:11: note: did you mean 'cpuset_getaffinity'?
/usr/include/sys/cpuset.h:159:5: note: 'cpuset_getaffinity' declared here
int cpuset_getaffinity(cpulevel_t, cpuwhich_t, id_t, size_t, cpuset_t *);
^
1 error generated.

Passing -D_WITH_CPU_SET_T to port's CFLAGS resolves this, but is this the
intended behavior for porters to consider after base 90fa9705d ?

bugzilla...@freebsd.org

unread,

Nov 14, 2021, 12:16:45 PM11/14/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #12 from tod.j...@gmail.com ---
wine-devel is also still affected:

gcc10 -m64 -c -o server/timer.o server/timer.c -Iserver -Iinclude -D__WINESRC__
-Wall -pipe -fcf-protection=none \
-fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement
-Wempty-body \
-Wignored-qualifiers -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2
-Wstrict-prototypes \
-Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings
-Wpointer-arith -Wlogical-op \
-isystem /usr/local/include -O2 -pipe -fstack-protector-strong
-Wl,-rpath=/usr/local/lib/gcc10 -isystem /usr/local/include
-fno-strict-aliasing
server/thread.c: In function 'set_thread_affinity':
server/thread.c:574:9: error: unknown type name 'cpu_set_t'; did you mean
'cpusetid_t'?
574 | cpu_set_t set;
| ^~~~~~~~~
| cpusetid_t
server/thread.c:578:9: warning: implicit declaration of function 'CPU_ZERO'
[-Wimplicit-function-declaration]
578 | CPU_ZERO( &set );
| ^~~~~~~~
server/thread.c:580:34: warning: implicit declaration of function 'CPU_SET';
did you mean 'L_SET'? [-Wimplicit-function-declaration]
580 | if (affinity & mask) CPU_SET( i, &set );
| ^~~~~~~
| L_SET
server/thread.c:582:15: warning: implicit declaration of function
'sched_setaffinity' [-Wimplicit-function-declaration]
582 | ret = sched_setaffinity( thread->unix_tid, sizeof(set), &set );
| ^~~~~~~~~~~~~~~~~
server/thread.c: In function 'get_thread_affinity':
server/thread.c:595:9: error: unknown type name 'cpu_set_t'; did you mean
'cpusetid_t'?
595 | cpu_set_t set;
| ^~~~~~~~~
| cpusetid_t
server/thread.c:598:14: warning: implicit declaration of function
'sched_getaffinity' [-Wimplicit-function-declaration]
598 | if (!sched_getaffinity( thread->unix_tid, sizeof(set), &set ))
| ^~~~~~~~~~~~~~~~~
server/thread.c:600:21: warning: implicit declaration of function 'CPU_ISSET';
did you mean 'FD_ISSET'? [-Wimplicit-function-declaration]
600 | if (CPU_ISSET( i, &set )) mask |= (affinity_t)1 << i;
| ^~~~~~~~~
| FD_ISSET
gmake[2]: *** [Makefile:177490: server/thread.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory '/usr/ports/emulators/wine-devel/work/wine-6.21'
===> Compilation failed unexpectedly.

bugzilla...@freebsd.org

unread,

Nov 15, 2021, 12:22:15 AM11/15/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #13 from Evgeniy Khramtsov <evg...@khramtsov.org> ---
(In reply to Charlie Li from comment #5)

> duplicate PRs rolling in

Triaging ports PRs related to newly exposed sched.h as duplicates, both:

- Leaves the community and port maintainers without dedicated threads on
Bugzilla on how approach change for each affected port, e.g.: disable
auto-detection of sched.h, pass _WITH_CPU_SET_T, something else what is
appropriate for a port.

- Make it harder to see the list of affected ports, e.g. see how LLVM 13 import
exp-run was organized in bug 258209.

bugzilla...@freebsd.org

unread,

Nov 15, 2021, 4:23:16 PM11/15/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #14 from Jan Beich <jbe...@FreeBSD.org> ---
According to base 90fa9705d5cd _WITH_CPU_SET_T is supposed to enable the new
functionality. If many ports are broken without it the conditional is pointless
and all regressions should be fixed the hard way (a la Clang upgrades).

AC_CHECK_FUNC(sched_getaffinity) from autotools and
meson.get_compiler('c').has_function('sched_getaffinity') test symbol
visibility without using #include <sched.h>. Such behavior is allowed in C
unlike C++ but often warned via -Wimplicit-function-declaration. For example,
GNU libc hides extensions like sched_getaffinity by default. However, NetBSD
added sched_getaffinity_np in 2008-10-31 and DragonFly added sched_getaffinity
in 2017-01-14, both following the BSD convention of exposing all extensions
unless standard conformance (e.g., _POSIX_C_SOURCE) is requested.

https://www.man7.org/linux/man-pages/man2/sched_getaffinity.2.html
https://man.dragonflybsd.org/?command=sched_getaffinity&section=2
https://man.netbsd.org/sched_getaffinity_np.3

After FreeBSD finally got rid of _WITH_GETLINE and _WITH_DPRINTF we now have
_WITH_CPU_SET_T to deal with. It's as ugly as cheating _POSIX_C_SOURCE by
defining __BSD_VISIBLE.

bugzilla...@freebsd.org

unread,

Nov 15, 2021, 6:19:51 PM11/15/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #15 from Konstantin Belousov <k...@FreeBSD.org> ---
(In reply to Jan Beich from comment #14)
If the ports' maintainers consensus is that _WITH_CPU_SET_T is useless I am
more than happy to get rid of this kludge. Apparently adding sched_XXX
functions cannot be done without some additional patching for ports, because
we cannot be fully compatible with glibc. This was not obvious before the
functionality was added, I use tcmalloc as some porting example there (and
the goal is really D32360 membarrier(2) and D32505 rseq(2)).

So whatever the decision is about _WITH_CPU_SET_T, I will do it.

bugzilla...@freebsd.org

unread,

Nov 18, 2021, 5:06:11 PM11/18/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Charlie Li <vis...@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------

CC| |ohar...@walstatt.org

--- Comment #16 from Charlie Li <vis...@freebsd.org> ---
*** Bug 259925 has been marked as a duplicate of this bug. ***

bugzilla...@freebsd.org

unread,

Nov 19, 2021, 4:57:07 PM11/19/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #17 from Kubilay Kocak <ko...@FreeBSD.org> ---
Do we want/need to request feedback from anyone specifically in ports to move
forward?

bugzilla...@freebsd.org

unread,

Nov 20, 2021, 7:36:06 PM11/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #18 from Konstantin Belousov <k...@FreeBSD.org> ---
I definitely want/need a feedback from ports maintainers. In particular:
1. Should sched_getaffinity(3), sched_setaffinity(3), and sched_getcpu()
prototypes
be available regardless of _WANT_CPU_SET_T? I suppose that yes, but need a
direct
answer.
2. Should cpu_set_t typedef available under _WANT_CPU_SET_T or just under
_BSD_VISIBLE? I do not have an opinion there, and suspect that removal of
_WANT_CPU_SET_T could indeed simplify some ports.

This is also some plan to stop exposing BIT_* API to userspace, so that it
gets less conflicts with namespace poluution just by pulling sched.h. But this
require some time to materialize.

Is there anything else src can help ports? There is more stuff planned, see
D32360 and D32505, but I expect these be much less problematic
(sched_getaffinity()
problems were indeed a surprise to me).

bugzilla...@freebsd.org

unread,

Nov 21, 2021, 10:03:08 AM11/21/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |Trond.E...@ximalas.inf
| |o

--- Comment #19 from Trond.E...@ximalas.info ---
Created attachment 229635
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229635&action=edit
Patch for graphics/cairo, for perf/cairo-perf-micro.c

bugzilla...@freebsd.org

unread,

Nov 21, 2021, 10:37:25 AM11/21/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------

Attachment #229635|0 |1
is obsolete| |

--- Comment #20 from Trond.E...@ximalas.info ---
Created attachment 229638
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229638&action=edit

bugzilla...@freebsd.org

unread,

Nov 22, 2021, 7:42:02 AM11/22/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Antoine Brodin <ant...@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Flags| |maintainer-feedback?(deskto
| |p...@FreeBSD.org)

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 5:43:22 AM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #21 from commi...@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/ports/commit/?id=ad03eb1e0a2f1a5af74070aa47ca837f2ab6ddb9

commit ad03eb1e0a2f1a5af74070aa47ca837f2ab6ddb9
Author: Trond Endrestøl <Trond.E...@ximalas.info>
AuthorDate: 2021-11-23 10:35:34 +0000
Commit: Tobias C. Berner <tcbe...@FreeBSD.org>
CommitDate: 2021-11-23 10:42:45 +0000

graphics/cairo: define _WITH_CPU_SET_T to fix build on -CURRENT

Changes in 90fa9705d5cd hide functionality behind _WITH_CPU_SET_T,
and require consumers to opt-in.

Error:
--- cairo-perf-micro.o ---
cairo-perf-micro.c:418:5: error: unknown type name 'cpu_set_t'; did
you mean 'cpusetid_t'?

cpu_set_t affinity;
^~~~~~~~~
cpusetid_t
/usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
typedef __cpusetid_t cpusetid_t;
^

PR: 259787

graphics/cairo/files/patch-perf_cairo-perf-micro.c (new) | 10 ++++++++++
1 file changed, 10 insertions(+)

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 6:05:29 AM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #22 from commi...@FreeBSD.org ---
A commit in branch 2021Q4 references this bug:

URL:
https://cgit.FreeBSD.org/ports/commit/?id=49dc1cc6ac16e0d53659717052997664b16f4970

commit 49dc1cc6ac16e0d53659717052997664b16f4970

Author: Trond Endrestøl <Trond.E...@ximalas.info>
AuthorDate: 2021-11-23 10:35:34 +0000
Commit: Tobias C. Berner <tcbe...@FreeBSD.org>

CommitDate: 2021-11-23 11:03:36 +0000

graphics/cairo: define _WITH_CPU_SET_T to fix build on -CURRENT

Changes in 90fa9705d5cd hide functionality behind _WITH_CPU_SET_T,
and require consumers to opt-in.

Error:
--- cairo-perf-micro.o ---
cairo-perf-micro.c:418:5: error: unknown type name 'cpu_set_t'; did
you mean 'cpusetid_t'?
cpu_set_t affinity;
^~~~~~~~~
cpusetid_t
/usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
typedef __cpusetid_t cpusetid_t;
^

PR: 259787

(cherry picked from commit ad03eb1e0a2f1a5af74070aa47ca837f2ab6ddb9)

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 7:01:49 AM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Tobias C. Berner <tcbe...@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tcbe...@freebsd.org
Flags|maintainer-feedback?(deskto |maintainer-feedback-
|p...@FreeBSD.org) |

--- Comment #23 from Tobias C. Berner <tcbe...@freebsd.org> ---
@Trond thanks for the patch -- committed.

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 7:02:01 AM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Tobias C. Berner <tcbe...@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------

Flags|maintainer-feedback- |maintainer-feedback+

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 10:03:06 AM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #24 from commi...@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/ports/commit/?id=2f6fd28d6732051e10edf81dd0a3e93f7d9bb86b

commit 2f6fd28d6732051e10edf81dd0a3e93f7d9bb86b
Author: Tobias C. Berner <tcbe...@FreeBSD.org>
AuthorDate: 2021-11-23 14:59:54 +0000

Commit: Tobias C. Berner <tcbe...@FreeBSD.org>

CommitDate: 2021-11-23 15:02:28 +0000

multimedia/gavl: opt in to sched* functions

Make sched* functions available as required by

https://cgit.freebsd.org/src/commit/?id=90fa9705d5cd29cf11c5dc7319299788dec2546a

benchmark.c:1854:7: warning: implicit declaration of function
'sched_setaffinity' is invalid in C99
[-Wimplicit-function-declaration] if(!sched_setaffinity(0,
sizeof(cpuset), &cpuset))

PR: 259787

multimedia/gavl/Makefile | 3 +++
1 file changed, 3 insertions(+)

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 12:05:25 PM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #25 from khb <khb...@gmail.com> ---
I believe lang/guile2 is also affected by this:

posix.c:2114:29: error: unknown type name 'cpu_set_t'; did you mean 'cpuset_t'?
cpu_set_to_bitvector (const cpu_set_t *cs)

^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

posix.c:2141:3: error: unknown type name 'cpu_set_t'; did you mean 'cpuset_t'?
cpu_set_t cs;

^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

posix.c:2144:9: warning: implicit declaration of function 'sched_getaffinity'

is invalid in C99 [-Wimplicit-function-declaration]

err = sched_getaffinity (scm_to_int (pid), sizeof (cs), &cs);
^
posix.c:2161:3: error: unknown type name 'cpu_set_t'; did you mean 'cpuset_t'?
cpu_set_t cs;

^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

posix.c:2180:9: warning: implicit declaration of function 'sched_setaffinity'

is invalid in C99 [-Wimplicit-function-declaration]

err = sched_setaffinity (scm_to_int (pid), sizeof (cs), &cs);
^
2 warnings and 3 errors generated.
gmake[5]: *** [Makefile:3540: libguile_2.2_la-posix.lo] Error 1
gmake[5]: Leaving directory '/usr/ports/lang/guile2/work/guile-2.2.7/libguile'
gmake[4]: *** [Makefile:2423: all] Error 2
gmake[4]: Leaving directory '/usr/ports/lang/guile2/work/guile-2.2.7/libguile'
gmake[3]: *** [Makefile:1857: all-recursive] Error 1
gmake[3]: Leaving directory '/usr/ports/lang/guile2/work/guile-2.2.7'
gmake[2]: *** [Makefile:1743: all] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/guile2/work/guile-2.2.7'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/guile2
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/guile2

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 12:07:55 PM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #26 from Larry Rosenman <l...@FreeBSD.org> ---
benchmarks/iperf3:
https://home.lerctr.org:8888/data/live-host-ports/2021-11-23_09h52m37s/logs/errors/iperf3-3.10.1_1.log

archivers/rpm4:
https://home.lerctr.org:8888/data/live-host-ports/2021-11-23_09h52m37s/logs/errors/iperf3-3.10.1_1.log

bugzilla...@freebsd.org

unread,

Nov 23, 2021, 12:09:15 PM11/23/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #27 from Larry Rosenman <l...@FreeBSD.org> ---
(In reply to Larry Rosenman from comment #26)
Umm, rpm4:
https://home.lerctr.org:8888/data/live-host-ports/2021-11-23_09h52m37s/logs/errors/rpm4-4.16.1.3_1.log

bugzilla...@freebsd.org

unread,

Nov 25, 2021, 1:40:07 AM11/25/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #28 from Trond.E...@ximalas.info ---
Created attachment 229718
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229718&action=edit
Patch for src/iperf_api.c

Should fix these errors:

iperf_api.c:4460:5: error: unknown type name 'cpu_set_t'; did you mean
'cpuset_t'?
cpu_set_t cpu_set;

^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

iperf_api.c:4464:9: warning: implicit declaration of function

'sched_setaffinity' is invalid in C99 [-Wimplicit-function-declaration]

if (sched_setaffinity(0, sizeof(cpu_set_t), &cpu_set) != 0) {
^
iperf_api.c:4464:37: error: use of undeclared identifier 'cpu_set_t'; did you
mean 'cpuset'?
if (sched_setaffinity(0, sizeof(cpu_set_t), &cpu_set) != 0) {
^~~~~~~~~
cpuset
/usr/include/sys/cpuset.h:156:5: note: 'cpuset' declared here
int cpuset(cpusetid_t *);
^
iperf_api.c:4506:5: error: unknown type name 'cpu_set_t'; did you mean
'cpuset_t'?
cpu_set_t cpu_set;

^~~~~~~~~
cpuset_t
/usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
typedef struct _cpuset cpuset_t;
^

iperf_api.c:4512:9: warning: implicit declaration of function

'sched_setaffinity' is invalid in C99 [-Wimplicit-function-declaration]

if (sched_setaffinity(0, sizeof(cpu_set_t), &cpu_set) != 0) {
^
iperf_api.c:4512:37: error: use of undeclared identifier 'cpu_set_t'; did you
mean 'cpuset'?
if (sched_setaffinity(0, sizeof(cpu_set_t), &cpu_set) != 0) {
^~~~~~~~~
cpuset
/usr/include/sys/cpuset.h:156:5: note: 'cpuset' declared here
int cpuset(cpusetid_t *);
^
2 warnings and 4 errors generated.

bugzilla...@freebsd.org

unread,

Nov 25, 2021, 1:42:20 AM11/25/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #29 from Trond.E...@ximalas.info ---

Created attachment 229719
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229719&action=edit

Patch for benchmarks/iperf3, for src/iperf_server_api.c

Previous submitted patch is also for benchmarks/iperf3.

bugzilla...@freebsd.org

unread,

Nov 25, 2021, 1:44:45 AM11/25/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #229718|Patch for src/iperf_api.c |Patch for
description| |benchmarks/iperf3, for
| |src/iperf_api.c

bugzilla...@freebsd.org

unread,

Nov 26, 2021, 11:37:28 AM11/26/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #30 from Trond.E...@ximalas.info ---
Created attachment 229745
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229745&action=edit
Patch for lang/ghc, for rts/posix/OSThreads.c

Should fix these errors:

rts/posix/OSThreads.c:314:5: error:

error: unknown type name 'cpu_set_t'; did you mean 'cpuset_t'?

| ^
typedef struct _cpuset cpuset_t;
^

rts/posix/OSThreads.c:322:5: error:

warning: implicit declaration of function 'sched_setaffinity' is invalid
in C99 [-Wimplicit-function-declaration]

sched_setaffinity(0, sizeof(cpu_set_t), &cs);
^
|
322 | sched_setaffinity(0, sizeof(cpu_set_t), &cs);
| ^

rts/posix/OSThreads.c:322:33: error:

error: use of undeclared identifier 'cpu_set_t'

sched_setaffinity(0, sizeof(cpu_set_t), &cs);
^
|
322 | sched_setaffinity(0, sizeof(cpu_set_t), &cs);
| ^
1 warning and 2 errors generated.
`cc' failed in phase `C Compiler'. (Exit code: 1)
gmake[2]: *** [rts/ghc.mk:325: rts/dist/build/posix/OSThreads.p_o] Error 1

bugzilla...@freebsd.org

unread,

Nov 27, 2021, 5:47:11 AM11/27/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------

Attachment #229745|0 |1
is obsolete| |

--- Comment #31 from Trond.E...@ximalas.info ---
Created attachment 229756
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229756&action=edit

Patch for lang/ghc, for rts/posix/OSThreads.c

sched.h is included somewhere earlier in this file. Define the macro
_WITH_CPU_SET_T at the top of the source file.

bugzilla...@freebsd.org

unread,

Dec 5, 2021, 5:25:27 PM12/5/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Stefan Eßer <s...@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
URL| |https://reviews.freebsd.org
| |/D33235
CC| |s...@FreeBSD.org

--- Comment #32 from Stefan Eßer <s...@FreeBSD.org> ---
This issue has been fixed in -CURRENT in commit 5e04571cf3cf by removing the
name space pollution due to the implicit inclusion of sys/bitset.h when sched.h
is included. This commit will be merged to 12-STABLE and 13-STABLE after 1
month.

The work-around of using -D_WITH_CPU_SET_T for ports that need the full
functionality contained in sched.h will be required until the last of the
currently supported releases is declared EoL.

Only after all supported FreeBSD releases have received the patched sched.h,
sys/bitset.h et.al. the -D_WITH_CPU_SET_T work-around may be removed from all
ports.

bugzilla...@freebsd.org

unread,

Dec 15, 2021, 10:56:13 PM12/15/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #33 from Jan Beich <jbe...@FreeBSD.org> ---
(In reply to Stefan Eßer from comment #32)

> Only after all supported FreeBSD releases have received the patched sched.h

Which ones? include/sched.h (with sched_{g,s}etaffinity) doesn't exist on
stable/13 and stable/12, let alone any -RELEASE. Besides, stable/* and "main"
are moving targets, so only the tip (latest revision) is supported.

bugzilla...@freebsd.org

unread,

Dec 16, 2021, 1:20:39 PM12/16/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #34 from Stefan Eßer <s...@FreeBSD.org> ---
(In reply to Jan Beich from comment #33)

Yes, I noticed that there had been no MFC to -STABLE yet.

But the latest sched.h in -CURRENT has caused a number of issues in ports:

Not depending on _WITH_CPU_SET_T causes some ports to assume that a number of
GLIBC specific macros or functions are available.

And there are conflicting requirements: the lang/gcc* ports fail if cpuset.h is
included and defines the CPU_ALLOC() macro, while libvirt assumes that a number
of GLIBC specific macros exist, including CPU_ALLOC() ...

The definitions of CPU_AND in GLIBC and CPU_AND2 in FreeBSD have the same
signatures, but CPU_AND exists in FreeBSD with different parameters.

I do not know how these issues can be fixed. The attempt to provide better
compatibility with GLIBC leads to port failures since full compatibility is
assumed by many ports that detect partial compatibility.

bugzilla...@freebsd.org

unread,

Dec 16, 2021, 2:54:01 PM12/16/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #35 from Konstantin Belousov <k...@FreeBSD.org> ---
(In reply to Stefan Eßer from comment #34)
There are some limitations how much can we do in base to not break existing
third party software, which depends on 100% compatibility with Linux, while
adding new APIs to FreeBSD. I think we need to stop somewhere, and claim that
further issues needs to be fixed in that problematic third-party sources.

It is not that FreeBSD change to add sched_get/setaffinity is unreasonable,
right? The functionality is useful and simplifies porting a lot of stuff
(I know this first-hand with ucx and tcmalloc examples), it is some cases
where unreasonable assumptions are made that existence of that API implies
Linux + glibc.

I tried to get opinions of ports maintainers that are affected by the issue.
I provided a mechanism like _WANT_CPU_SET_T that makes some incompatible API
visibility optional. All I get in response was a silence.

I do want to merge this sched.h changes and new API to stable/13, mostly
because
I want membarrier(2) and rseq(2). and sched changes a prerequisites. The MFC
would clearly require some coordination
with Stefan to also get the follow-ups merged right after the base merge.

It is up to ports to handle fallouts now, I believe.

bugzilla...@freebsd.org

unread,

Dec 17, 2021, 9:11:24 AM12/17/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Gleb Popov <arr...@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |arr...@FreeBSD.org

--- Comment #36 from Gleb Popov <arr...@FreeBSD.org> ---
lang/ghc build fine now, so no patching needed.

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 3:05:43 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #37 from Stefan Eßer <s...@FreeBSD.org> ---
(In reply to Gleb Popov from comment #36)
Building lang/ghc on -CURRENT works after commit 5e04571cf3cf, which removed
the need to specify -D_WITH_CPU_SET_T to make parts of sched.h visible.

But I'm not sure whether that part of the commit should not be reverted, since
it made some ports assume that they were being built on a Linux system with
GLIBC.

Some of the CPU_* macros have conflicting signatures on FreeBSD and in GLIBC,
and now some ports need individual patches to make them build.

It may be better to just rely on the standard method of passing
-D_WITH_CPU_SET_T to enable those macros, than to expect port maintainers to
find the individual cure for their ports ...

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 5:56:07 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #38 from Trond.E...@ximalas.info ---
We can mark all my patches as obsolete since their respective ports now build
without any special care.

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 5:57:30 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #229638|0 |1
is obsolete| |

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 5:58:13 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------

Attachment #229718|0 |1

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 5:58:23 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------

Attachment #229719|0 |1

bugzilla...@freebsd.org

unread,

Dec 20, 2021, 5:58:34 PM12/20/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Trond.E...@ximalas.info changed:

What |Removed |Added
----------------------------------------------------------------------------

Attachment #229756|0 |1

bugzilla...@freebsd.org

unread,

Dec 21, 2021, 4:09:51 AM12/21/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #39 from Konstantin Belousov <k...@FreeBSD.org> ---
Comments #37 and #38 are somewhat contradictory. Only somewhat because there
could
be ports that break, despite some other ports are fixed.

Can anybody summarize the state as for today?

bugzilla...@freebsd.org

unread,

Dec 21, 2021, 11:53:49 PM12/21/21

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #40 from Konstantin Belousov <k...@FreeBSD.org> ---
(In reply to Konstantin Belousov from comment #39)
Ok, sched.h with all changes accumulated so far goes into stable/13 at
the weekend.

bugzilla...@freebsd.org

unread,

Apr 30, 2022, 5:26:06 PM4/30/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Eugene Grosbein <eu...@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |eu...@freebsd.org

--- Comment #41 from Eugene Grosbein <eu...@freebsd.org> ---
Build of www/squid 5.5 (ports tree of today) is broken on 13.1-STABLE/amd64 of
16 April 2022. So, what's decided - should I bother squid maintainer or will
this be fixed in base?

gmake[5]: Entering directory '/usr/ports/www/squid/work/squid-5.5/src'
depbase=`echo CpuAffinity.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/usr/local/etc/squid/squid.conf\"
-DDEFAULT_SQUID_DATA_
DIR=\"/usr/local/etc/squid\"
-DDEFAULT_SQUID_CONFIG_DIR=\"/usr/local/etc/squid\" -I.. -I../includ
e -I../lib -I../src -I../include -I../libltdl -I../src -I../libltdl -isystem
/usr/local/include
-D_REENTRANT -O2 -pipe -fstack-protector-strong -isystem /usr/local/include
-fno-strict-aliasing -
isystem /usr/local/include -I/usr/local/include -MT CpuAffinity.o -MD -MP -MF
$depbase.Tpo -c -o C
puAffinity.o CpuAffinity.cc &&\
mv -f $depbase.Tpo $depbase.Po
In file included from CpuAffinity.cc:15:
In file included from ../src/CpuAffinitySet.h:12:
../compat/cpu.h:42:31: error: unknown type name 'cpu_set_t'; did you mean
'cpusetid_t'?
inline void CpuSet(int, const cpu_set_t *) {}

^~~~~~~~~
cpusetid_t
/usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
typedef __cpusetid_t cpusetid_t;

bugzilla...@freebsd.org

unread,

Apr 30, 2022, 5:30:20 PM4/30/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #42 from Stefan Eßer <s...@FreeBSD.org> ---
(In reply to Eugene Grosbein from comment #41)

Thank you for reporting the issue for www/squid on 13.1-STABLE.

I'll look into this issue some time next week ...

bugzilla...@freebsd.org

unread,

May 1, 2022, 2:12:59 PM5/1/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #43 from Stefan Eßer <s...@FreeBSD.org> ---

(In reply to Eugene Grosbein from comment #41)

The www/squid port built successfully for me on the following platforms:

VERSION ARCH
12.3-RELEASE-p5 amd64
13.0-RELEASE-p5 i386
13.1-RC5 amd64
14-CURRENT amd64

Please provide details how to reproduce this issue (e.g. OPTIONs, full build
log, ...).

bugzilla...@freebsd.org

unread,

Jun 27, 2022, 8:03:04 PM6/27/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #44 from Eugene Grosbein <eu...@freebsd.org> ---
(In reply to Stefan Eßer from comment #43)

Sorry for long delay, I somehow missed your request.

I've just updated my ports tree that has www/squid version 5.6 now. Same error
persists. I attach /var/db/www_squid/options and full port build log that is
large, so it comes compressed.

bugzilla...@freebsd.org

unread,

Jun 27, 2022, 8:03:58 PM6/27/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #45 from Eugene Grosbein <eu...@freebsd.org> ---
Created attachment 234976
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234976&action=edit
www/squid 5.6 build error

bugzilla...@freebsd.org

unread,

Jun 27, 2022, 8:04:46 PM6/27/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #46 from Eugene Grosbein <eu...@freebsd.org> ---
Created attachment 234977
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234977&action=edit
/var/db/ports/www_squid/options

bugzilla...@freebsd.org

unread,

Jun 28, 2022, 2:59:23 PM6/28/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #47 from Stefan Eßer <s...@FreeBSD.org> ---
(In reply to Eugene Grosbein from comment #44)

Thank you for providing the build log and options.

I have just rebuilt squid-5.6 on -CURRENT/amd64 with default options and then
with the options provided in comment 46.

Both builds succeeded without issue, as did the "poudriere testport" builds in
my 3 test jails:

amd64/12.3
amd64/13.1
i386/13.0

The 12.3 and 13.0 releases did not have the GLIBC compatible CPU_SET functions,
13.1 and -CURRENT do. I'm using this mix of releases in order to cover
different compilers and system headers of the currently supported releases.

There are packages of squid-5.6 for many releases and architectures, see:

https://www.freshports.org/www/squid/

And this is near the end of the successful "poudriere testport" run on
amd/13.1:

> gmake[3]: Leaving directory '/wrkdirs/usr/ports/www/squid/work/squid-5.6'
> gmake[2]: Leaving directory '/wrkdirs/usr/ports/www/squid/work/squid-5.6'
> gmake[1]: Leaving directory '/wrkdirs/usr/ports/www/squid/work/squid-5.6'
> install -m 0644 /wrkdirs/usr/ports/www/squid/work/squid-5.6/src/auth/basic/DB/passwd.sql /wrkdirs/usr/ports/www/squid/work/stage/usr/local/share/examples/squid
> (cd /wrkdirs/usr/ports/www/squid/work/squid-5.6 && install -m 0644 QUICKSTART README RELEASENOTES.html doc/debug-sections.txt /wrkdirs/usr/ports/www/squid/work/stage/usr/local/share/doc/squid)
> ====> Compressing man pages (compress-man)
> ===> Staging rc.d startup script(s)
> ===========================================================================
> ====> Running Q/A tests (stage-qa)
> ====> Checking for pkg-plist issues (check-plist)
> ===> Parsing plist
> ===> Checking for items in STAGEDIR missing from pkg-plist
> ===> Checking for items in pkg-plist which are not in STAGEDIR
> ===> No pkg-plist issues found (check-plist)
> =>> Checking for staging violations... done
> =======================<phase: package >============================
> ===== env: DEVELOPER_MODE=yes PACKAGES=/tmp/pkgs PKGREPOSITORY=/tmp/pkgs PKGLATESTREPOSITORY=/tmp/pkgs/Latest 'PKG_NOTES=build_timestamp built_by' 'PKG_NOTE_build_timestamp=2022-06-28T18:09:38+0000' 'PKG_NOTE_built_by=poudriere-git-3.3.99.20220617' STRICT_DEPENDS=yes USER=root UID=0 GID=0
> ===> Building package for squid-5.6
> ===========================================================================
> =>> Recording filesystem state for preinst... done
> =======================<phase: install >============================
> ===== env: DEVELOPER_MODE=yes STRICT_DEPENDS=yes USER=root UID=0 GID=0
> ===> Installing for squid-5.6
> ===> Checking if squid is already installed

The build log on other architectures and releases differs in the order of
execution of the compiler due to the parallel make, but not in other aspects.

One thing that I noticed is that the compiler is invoked with different options
in my successful tests and your log file.

Your failed compilation:

> depbase=`echo CpuAffinity.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\

> c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/usr/local/etc/squid/squid.conf\" -DDEFAULT_SQUID_DATA_DIR=\"/usr/local/etc/squid\" -DDEFAULT_SQUID_CONFIG_DIR=\"/usr/local/etc/squid\" -I.. -I../include -I../lib -I../src -I../include -I../libltdl -I../src -I../libltdl -isystem /usr/local/include -D_REENTRANT -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -I/usr/local/include -MT CpuAffinity.o -MD -MP -MF $depbase.Tpo -c -o CpuAffinity.o CpuAffinity.cc &&\

> mv -f $depbase.Tpo $depbase.Po
> In file included from CpuAffinity.cc:15:
> In file included from ../src/CpuAffinitySet.h:12:
> ../compat/cpu.h:42:31: error: unknown type name 'cpu_set_t'; did you mean 'cpusetid_t'?
> inline void CpuSet(int, const cpu_set_t *) {}
> ^~~~~~~~~
> cpusetid_t
> /usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
> typedef __cpusetid_t cpusetid_t;

> ^

My successful invocation explicitly includes /usr/include:

> depbase=`echo CpuAffinity.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\

> c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/usr/local/etc/squid/squid.conf\" -DDEFAULT_SQUID_DATA_DIR=\"/usr/local/etc/squid\" -DDEFAULT_SQUID_CONFIG_DIR=\"/usr/local/etc/squid\" -I.. -I../include -I../lib -I../src -I../include -I/usr/include -I/usr/include -I../libltdl -I../src -I../libltdl -I/usr/include -I/usr/include -I/usr/include -isystem /usr/local/include -D_REENTRANT -I/usr/include -I/usr/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -I/usr/local/include -MT CpuAffinity.o -MD -MP -MF $depbase.Tpo -c -o CpuAffinity.o CpuAffinity.cc &&\
> mv -f $depbase.Tpo $depbase.Po

That's the only difference that I could spot.

Since this issue does not seem to exist on the official package builders and
has not been reported by anybody else, it seems mostly likely that there is a
local issue on your build host ...

bugzilla...@freebsd.org

unread,

Jun 28, 2022, 4:29:40 PM6/28/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

--- Comment #48 from Eugene Grosbein <eu...@freebsd.org> ---
(In reply to Stefan Eßer from comment #47)

Thank you very much for jour attention. Now I think the failure was due to my
experiments with world build speedup. I was sure I undid my local changes but
apparently not all of it.

I've just updated my stable/13 system again carefully with all unsafe knobs
turned off and www/squid builds just fine after installworld etc.

bugzilla...@freebsd.org

unread,

Jun 28, 2022, 5:09:13 PM6/28/22

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Stefan Eßer <s...@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|In Progress |Closed
Resolution|--- |FIXED

--- Comment #49 from Stefan Eßer <s...@FreeBSD.org> ---
(In reply to Eugene Grosbein from comment #48)

OK, thank you for the update and I'm glad that squid builds for you, again.

I'm going to close this PR now. There has been no other report of an
outstanding issue that might be due to the CPU_SET changes performed more than
6 months ago.

bugzilla...@freebsd.org

unread,

Apr 21, 2023, 8:54:17 AM4/21/23

to multi...@freebsd.org

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787

Ross McKelvie <ro...@exitzero.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks| |270977

Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270977
[Bug 270977] multimedia/dav1d: Fails to build with TEST=ON due to missing
typedef cpu_set_t

Reply all

Reply to author

Forward