Date: Thu, 16 Dec 2021 18:20:34 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 259787] sched.h: unknown type name 'cpu_set_t' after 160b4b922b6021848b6b48afc894d16b879b7af2 Message-ID: <bug-259787-39348-W5zgVJLNwc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259787-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-259787-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 --- Comment #34 from Stefan E=C3=9Fer <se@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 nu= mber 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259787-39348-W5zgVJLNwc>