cc -I. -I./ -DLIBICONV_PLUG -isystem /usr/local/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avutil -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include -I/usr/local/include/libvmaf -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/fribidi -I/usr/local/include -I/usr/local/include -I/usr/local/include/libdrm -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/opus -I/usr/local/include/opus -I/usr/local/include -I/usr/local/include -I/usr/local/include/libvmaf -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DX264_API_IMPORTS -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -pthread -I/usr/local/include -pthread -I/usr/local/include -pthread -I/usr/local/include -pthread -I/usr/local/include -I/usr/local/include/libdrm -I/usr/local/include -I/usr/local/include -I/usr/local/include -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 -fno-math-errno -fno-signed-zeros -mstack-alignment=16 -Qunused-arguments -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -MMD -MF libavutil/crc.d -MT libavutil/crc.o -c -o libavutil/crc.o libavutil/crc.c libavutil/cpu.c:284:5: error: unknown type name 'cpu_set_t'; did you mean 'cpuset_t'? cpu_set_t cpuset; ^~~~~~~~~ cpuset_t /usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here typedef struct _cpuset cpuset_t; ^ 2 warnings and 1 error generated.
Sadly this probably affects all libavutil consumers, such as projects bundling it. I at least reproduced it with one project outside of the ports tree.
This should be fixed soon; see: discussion on dev-commits-src-main@ re: "git: 160b4b922b60 - main - Add real sched.h"
Ah, thanks. I went ahead and subscribed. In the meantime I just patched it since I didn't have much luck messing with the headers on my own. --- libavutil/cpu.c.orig 2021-10-24 14:47:11.000000000 -0600 +++ libavutil/cpu.c 2021-11-11 18:50:52.941062000 -0700 @@ -281,7 +281,11 @@ SYSTEM_INFO sysinfo; #endif #if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) + #ifdef __FreeBSD__ + cpuset_t cpuset; + #else cpu_set_t cpuset; + #endif CPU_ZERO(&cpuset);
OK, cool. I'm going to hand this PR over to kib@ to close when he commits the follow-up. Thanks for the report!
There is a growing pkg-fallout list, so genericising the title and components a bit to prepare for duplicate PRs rolling in.
*** Bug 259801 has been marked as a duplicate of this bug. ***
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 ))
kib@ has committed base 90fa9705d5cd29cf11c5dc7319299788dec2546a, try updating to or past.
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.
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.
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 ?
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.
(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.
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§ion=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.
(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.
*** Bug 259925 has been marked as a duplicate of this bug. ***
Do we want/need to request feedback from anyone specifically in ports to move forward?
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).
Created attachment 229635 [details] Patch for graphics/cairo, for perf/cairo-perf-micro.c
Created attachment 229638 [details] Patch for graphics/cairo, for perf/cairo-perf-micro.c
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ad03eb1e0a2f1a5af74070aa47ca837f2ab6ddb9 commit ad03eb1e0a2f1a5af74070aa47ca837f2ab6ddb9 Author: Trond Endrestøl <Trond.Endrestol@ximalas.info> AuthorDate: 2021-11-23 10:35:34 +0000 Commit: Tobias C. Berner <tcberner@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(+)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=49dc1cc6ac16e0d53659717052997664b16f4970 commit 49dc1cc6ac16e0d53659717052997664b16f4970 Author: Trond Endrestøl <Trond.Endrestol@ximalas.info> AuthorDate: 2021-11-23 10:35:34 +0000 Commit: Tobias C. Berner <tcberner@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) graphics/cairo/files/patch-perf_cairo-perf-micro.c (new) | 10 ++++++++++ 1 file changed, 10 insertions(+)
@Trond thanks for the patch -- committed.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2f6fd28d6732051e10edf81dd0a3e93f7d9bb86b commit 2f6fd28d6732051e10edf81dd0a3e93f7d9bb86b Author: Tobias C. Berner <tcberner@FreeBSD.org> AuthorDate: 2021-11-23 14:59:54 +0000 Commit: Tobias C. Berner <tcberner@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(+)
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
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
(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
Created attachment 229718 [details] Patch for benchmarks/iperf3, 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.
Created attachment 229719 [details] Patch for benchmarks/iperf3, for src/iperf_server_api.c Previous submitted patch is also for benchmarks/iperf3.
Created attachment 229745 [details] 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'? cpu_set_t cs; ^~~~~~~~~ cpuset_t | 314 | cpu_set_t cs; | ^ /usr/include/sys/_cpuset.h:50:24: error: note: 'cpuset_t' declared here | 50 | typedef struct _cpuset 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
Created attachment 229756 [details] 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.
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.
(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.
(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.
(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.
lang/ghc build fine now, so no patching needed.
(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 ...
We can mark all my patches as obsolete since their respective ports now build without any special care.
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?
(In reply to Konstantin Belousov from comment #39) Ok, sched.h with all changes accumulated so far goes into stable/13 at the weekend.
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;
(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 ...
(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, ...).
(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.
Created attachment 234976 [details] www/squid 5.6 build error
Created attachment 234977 [details] /var/db/ports/www_squid/options
(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 ...
(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.
(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.