pkg-fallout reports a number of broken ports with Host OSVERSION >= 1100066 due to changes in 11.0-CURRENT kernel [1] that the package cluster hosts various -RELEASE jails on. The issue can be worked around by disabling PCH [2] in the affected ports. Maintainers of the broken ports are CC'd. http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/assaultcube-1.2.0.2_3.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/codeblocks-13.12_4.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/evolvotron-0.6.3_2.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/fracplanet-0.4.0_8.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/last.fm-1.5.4.26862_5.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/leocad-0.80.3_2.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/murmur-1.2.8_1.log http://beefy1.isc.freebsd.org/data/93i386-default/385145/logs/sigil-0.6.0_5.log See also: http://thread.gmane.org/gmane.os.freebsd.devel.cvs/523979 [1] https://secure.freshbsd.org/search?project=freebsd-ports&q=PCH [2]
Some of the affected ports are unmaintained: devel/codeblocks graphics/evolvotron graphics/fracplanet audio/last.fm textproc/sigil
I've fixed audio/mumble and audio/murmur which were affected
A commit references this bug: Author: jbeich Date: Thu May 7 10:05:52 UTC 2015 New revision: 385615 URL: https://svnweb.freebsd.org/changeset/ports/385615 Log: textproc/sigil: unbreak build on the package cluster (PCH) PR: 199905 Changes: head/textproc/sigil/Makefile
What does this have to do with named ports? It's either kernel or gcc bug and should be fixed there. Please rollback all "fixes" for ports mentioned in this PR.
(In reply to Dmitry Marakasov from comment #4) This has already been covered in this commit log https://svnweb.freebsd.org/ports?view=revision&revision=384056 There is no interest in hacking gcc to play nice with pch, and it doesn't make sense because the older releases that have gcc as the base compiler are not going to continue to receive updates. It's much easier to just patch a dozen ports and move on.
(In reply to Mark Felder from comment #5) > (In reply to Dmitry Marakasov from comment #4) > > This has already been covered in this commit log > > https://svnweb.freebsd.org/ports?view=revision&revision=384056 > > There is no interest in hacking gcc to play nice with pch, and it doesn't > make sense because the older releases that have gcc as the base compiler are > not going to continue to receive updates. It's much easier to just patch a > dozen ports and move on. Yup. Thanks for linking my commit. Just disable PCH and move on. Building a fixed GCC to build with is not useful here.
FYI, you are going to want to mfh to the quarterly branch as well. I am getting emails about my ports failing to build for the quarterly branch.
(In reply to Mark Felder from comment #7) > FYI, you are going to want to mfh to the quarterly branch as well. I am > getting emails about my ports failing to build for the quarterly branch. It was in April: https://svnweb.freebsd.org/changeset/ports/384168
Refreshing the list (2 new) as beefy*.isc are offline. Not all of them appear on -quaterly probably because poudriere haven't obsoleted existing packages. http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/bloodfrontier-b2_10.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/codeblocks-13.12_4.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/evolvotron-0.6.3_2.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/fracplanet-0.4.0_8.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/last.fm-1.5.4.26862_5.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/leocad-0.80.3_2.log http://beefy7.nyi.freebsd.org/data/93i386-default/386108/logs/errors/sauerbraten-20130203_3.log
(In reply to Bryan Drewery from comment #6) I've read the thread, but not sure if I understood it correctly, so just to be sure: - the problem is only with base gcc (e.g. pre-10.x or arches which do not use clang yet such as mips) as it couldn't be updated right away - it can be fixed by using gcc from ports or disabling PCH Is this correct? Either way, I'd really prefer such fixes to be OSVERSION-dependent so they may be removed as soon as all problematic FreeBSD versions are EoL'ed.
(In reply to Dmitry Marakasov from comment #10) Yes and it only happens when you have a 11.0-CURRENT kernel, so these 8.x and 9.x environments are in jails being used to build these ports which is exactly how the official package building servers are setup. If a user wanted to build these ports/packages on 9.3-RELEASE, for example, it would work fine without this change.
I'd advise testing prior applying OSVERSION checks. For one, games/assaultcube before ports r385392 doesn't build even with lang/gcc and 10.1R i386 userland: /usr/lib/crt1.o: In function `_start1': /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x156): undefined reference to `main' collect2: error: ld returned 1 exit status Makefile:130: recipe for target 'cube.h.gch' failed gmake[1]: *** [cube.h.gch] Error 1 Similar error occurs with textproc/sigil.
(In reply to Jan Beich from comment #12) As far as I remember, gcc from ports has some problems with precompiled headers by itself. I've ran into it in games/redeclipse. Also, what are OSVERSION in which gcc was fixed? Actually I don't see relevant commits to contrib/gcc even in HEAD. Am I looking in a wrong place?
Also, won't today's ENs solve this?
(In reply to Dmitry Marakasov from comment #13) GCC was not fixed. Nobody is committing changes to GCC to fix the precompiled headers bug. I'm not sure how the recent ENs would have any affect on this issue since they have nothing to do with the 11-CURRENT kernel exhibiting this behavior.
(In reply to Mark Felder from comment #15) In my understanding, base gcc in all FreeBSD branches should have been fixed to work fine under 11 kernel. It may not require it's own EN as it's mainly related to pkg cluster, however it could have been pushed to the cluster with other ENs.
A commit references this bug: Author: jbeich Date: Thu May 14 19:03:05 UTC 2015 New revision: 386354 URL: https://svnweb.freebsd.org/changeset/ports/386354 Log: MFH: r385615 textproc/sigil: unbreak build on the package cluster (PCH) PR: 199905 Approved by: /head @ r385020 Approved by: ports-secteam (delphij) Changes: _U branches/2015Q2/ branches/2015Q2/textproc/sigil/Makefile
(In reply to Dmitry Marakasov from comment #13) > (In reply to Jan Beich from comment #12) > As far as I remember, gcc from ports has some problems with precompiled > headers by itself. I've ran into it in games/redeclipse. > > Also, what are OSVERSION in which gcc was fixed? Actually I don't see > relevant commits to contrib/gcc even in HEAD. Am I looking in a wrong place? It hasn't been fixed. It needs to be, but doesn't change this PR at all as noted before. Sure an EN would be great if there was a fix for gcc and re@ cared enough to release it. I doubt they would deem it worth the effort. Even then I would still want the changes in this PR since it's not reasonable to expect people to have the latest EN installed to avoid a build error that is easily avoided and only was there for a slight build optimization. Also note that while this issue is appearing on 11, it has been a bug in GCC for over a decade IIRC. Just google for the issue and you'll find references to it for other systems as well. The GCC PCH errors did occur with FreeBSD <11 with boost quite often for me as well. The changes in 11 just make it more consistently obviously broken.
games/bloodfrontier, games/sauerbraten fixed
I've fixed remaining ports mentioned in this PR. Seems like it can be closed now.