Created attachment 237899 [details] sysutils/wmflame: fix build with -fno-common While we are at it, at missing USE_XORG=xext Tested with Poudriere on armv7 arm64 FreeBSD 13.1. Please MFH if possible.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=eb0fbcfdfa6ec1203d95bc81ddeb1151698e79e8 commit eb0fbcfdfa6ec1203d95bc81ddeb1151698e79e8 Author: Robert Clausecker <fuz@fuz.su> AuthorDate: 2022-11-07 04:18:52 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2022-11-07 04:18:52 +0000 sysutils/wmflame: fix the port's build against -fno-common Ensure that there is only one variable definition per each object, as the C (and C++) standards mandated for years and compilers started to enforce as of recently (Clang 11, GCC 10). While we are at it, at missing `xext' component to the USE_XORG list. PR: 267600 sysutils/wmflame/Makefile | 5 +---- sysutils/wmflame/files/patch-wmgeneral_wmgeneral.c (new) | 12 ++++++++++++ sysutils/wmflame/files/patch-wmgeneral_wmgeneral.h (new) | 15 +++++++++++++++ 3 files changed, 28 insertions(+), 4 deletions(-)
It's a bit unfortunate that patches files are outside WRKSRC which is set too tight. I'll normalize things in a separate commit, hopefully making easier for Git to track history.
(In reply to Alexey Dokuchaev from comment #2) Was there something wrong with the solution I proposed (setting WRKSRC and BUILD_WRKSRC)?
(In reply to Robert Clausecker from comment #3) Maybe not, just haven't deeply evaluated it yet.
Any particular reason this has not been merged into 2022Q4 yet? Is there anything I can do?
(In reply to Robert Clausecker from comment #5) > Any particular reason this has not been merged into 2022Q4 yet? Sorry, but I don't do quarterlies; the way they're being handled now is IMHO wrong as it should be strictly ports-secteam@ territory, but I'll try to find someone who might help. > Is there anything I can do? Maybe drop an email to freebsd-ports@?
(In reply to Alexey Dokuchaev from comment #6) So... you do agree that this should be merged into 2022Q4 but don't want to do it yourself? I can find another committer, that's no problem.
(In reply to Robert Clausecker from comment #7) > So... you do agree that this should be merged into 2022Q4 No, I don't: in my understanding, only security or otherwise critical bugfixes should be merged to quarterlies, but as I've said, they are currently mishandled, essentially being slightly less turbulent and more outdated version of the trunk. But since these branches are joke anyways, I don't mind if someone wants to do the (useless) merge. Let people play with their toys if it's not hurting others, and quarterlies is a nice sandbox for that matter. :-)
I understand. Have a good day!