Date: Tue, 28 Jun 2022 18:59:19 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 259787] sched.h: unknown type name 'cpu_set_t' after 160b4b922b6021848b6b48afc894d16b879b7af2 Message-ID: <bug-259787-12827-BRAjJuUeH0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259787-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-259787-12827@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 #47 from Stefan E=C3=9Fer <se@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 th= en with the options provided in comment 46. Both builds succeeded without issue, as did the "poudriere testport" builds= in=20 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 functi= ons, 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/bas= ic/DB/passwd.sql /wrkdirs/usr/ports/www/squid/work/stage/usr/local/share/e= xamples/squid > (cd /wrkdirs/usr/ports/www/squid/work/squid-5.6 && install -m 0644 QUICK= START README RELEASENOTES.html doc/debug-sections.txt /wrkdirs/usr/ports/ww= w/squid/work/stage/usr/local/share/doc/squid) > =3D=3D=3D=3D> Compressing man pages (compress-man) > =3D=3D=3D> Staging rc.d startup script(s) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > =3D=3D=3D=3D> Running Q/A tests (stage-qa) > =3D=3D=3D=3D> Checking for pkg-plist issues (check-plist) > =3D=3D=3D> Parsing plist > =3D=3D=3D> Checking for items in STAGEDIR missing from pkg-plist > =3D=3D=3D> Checking for items in pkg-plist which are not in STAGEDIR > =3D=3D=3D> No pkg-plist issues found (check-plist) > =3D>> Checking for staging violations... done > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<pha= se: package >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D env: DEVELOPER_MODE=3Dyes PACKAGES=3D/tmp/pkgs PKGREPOSIT= ORY=3D/tmp/pkgs PKGLATESTREPOSITORY=3D/tmp/pkgs/Latest 'PKG_NOTES=3Dbuild_t= imestamp built_by' 'PKG_NOTE_build_timestamp=3D2022-06-28T18:09:38+0000' 'P= KG_NOTE_built_by=3Dpoudriere-git-3.3.99.20220617' STRICT_DEPENDS=3Dyes USER= =3Droot UID=3D0 GID=3D0 > =3D=3D=3D> Building package for squid-5.6 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > =3D>> Recording filesystem state for preinst... done > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<pha= se: install >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D env: DEVELOPER_MODE=3Dyes STRICT_DEPENDS=3Dyes USER=3Droo= t UID=3D0 GID=3D0 > =3D=3D=3D> Installing for squid-5.6 > =3D=3D=3D> 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 aspect= s. One thing that I noticed is that the compiler is invoked with different opt= ions in my successful tests and your log file. Your failed compilation: > depbase=3D`echo CpuAffinity.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=3D\"/usr/local/etc/squid/squid.= conf\" -DDEFAULT_SQUID_DATA_DIR=3D\"/usr/local/etc/squid\" -DDEFAULT_SQUID_= CONFIG_DIR=3D\"/usr/local/etc/squid\" -I.. -I../include -I../lib -I../src= -I../include -I../libltdl -I../src -I../libltdl -isystem /usr/local/inc= lude -D_REENTRANT -O2 -pipe -fstack-protector-strong -isystem /usr/local/in= clude -fno-strict-aliasing -isystem /usr/local/include -I/usr/local/inclu= de -MT CpuAffinity.o -MD -MP -MF $depbase.Tpo -c -o CpuAffinity.o CpuAffini= ty.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=3D`echo CpuAffinity.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=3D\"/usr/local/etc/squid/squid.= conf\" -DDEFAULT_SQUID_DATA_DIR=3D\"/usr/local/etc/squid\" -DDEFAULT_SQUID_= CONFIG_DIR=3D\"/usr/local/etc/squid\" -I.. -I../include -I../lib -I../src= -I../include -I/usr/include -I/usr/include -I../libltdl -I../src -I../l= ibltdl -I/usr/include -I/usr/include -I/usr/include -isystem /usr/local/i= nclude -D_REENTRANT -I/usr/include -I/usr/include -O2 -pipe -fstack-protect= or-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/l= ocal/include -I/usr/local/include -MT CpuAffinity.o -MD -MP -MF $depbase.T= po -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 ... --=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-12827-BRAjJuUeH0>