Date: Fri, 30 Jan 2026 20:36:14 -0800 From: Mark Millard <marklmi@yahoo.com> To: Daniel Engberg <diizzy@FreeBSD.org>, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org Subject: Re: git: 86e6270acf63 - main - devel/cmake-core: Use fat LTO instead of thin LTO Message-ID: <c0a4146e-87fa-437b-9385-c6a488d89740@yahoo.com> In-Reply-To: <697d5c55.22425.56b073ba__47992.9168870271$1769823347$gmane$org@gitrepo.freebsd.org>
index | next in thread | previous in thread | raw e-mail
On 1/30/26 17:35, Daniel Engberg wrote: > The branch main has been updated by diizzy: > > URL: https://cgit.FreeBSD.org/ports/commit/?id=86e6270acf631ba6328693b5b33f4ef74ac7cbac > > commit 86e6270acf631ba6328693b5b33f4ef74ac7cbac > Author: Daniel Engberg <diizzy@FreeBSD.org> > AuthorDate: 2026-01-31 00:46:15 +0000 > Commit: Daniel Engberg <diizzy@FreeBSD.org> > CommitDate: 2026-01-31 01:34:56 +0000 > > devel/cmake-core: Use fat LTO instead of thin LTO > > As we hardcode thin LTO to one thread [1] without any resolve for more > than a year use fat which performs better > > 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281765 > > PR: 292178 > Approved by: timeout (no objections for 3+ weeks) > Exp-run by: antoine > --- > devel/cmake-core/Makefile | 1 + > devel/cmake-core/files/patch-Modules_Compiler_Clang.cmake | 11 +++++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/devel/cmake-core/Makefile b/devel/cmake-core/Makefile > index d448bcb43277..533042192c3b 100644 > --- a/devel/cmake-core/Makefile > +++ b/devel/cmake-core/Makefile > @@ -1,5 +1,6 @@ > PORTNAME= cmake > DISTVERSION= ${_CMAKE_VERSION} > +PORTREVISION= 1 > CATEGORIES= devel > PKGNAMESUFFIX= -core > > diff --git a/devel/cmake-core/files/patch-Modules_Compiler_Clang.cmake b/devel/cmake-core/files/patch-Modules_Compiler_Clang.cmake > new file mode 100644 > index 000000000000..c66241d24931 > --- /dev/null > +++ b/devel/cmake-core/files/patch-Modules_Compiler_Clang.cmake > @@ -0,0 +1,11 @@ > +--- Modules/Compiler/Clang.cmake.orig 2026-01-04 12:06:32 UTC > ++++ Modules/Compiler/Clang.cmake > +@@ -62,7 +62,7 @@ else() > + # '-flto=thin' available since Clang 3.9 and Xcode 8 > + # * http://clang.llvm.org/docs/ThinLTO.html#clang-llvm > + # * https://trac.macports.org/wiki/XcodeVersionInfo > +- set(_CMAKE_LTO_THIN TRUE) > ++ #set(_CMAKE_LTO_THIN TRUE) > + if(__is_apple_clang) > + if(CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 8.0) > + set(_CMAKE_LTO_THIN FALSE) > > This change may need to be monitored, as, so far as I know, exp-runs do not test for issues like, given the various official builder-machine RAM+SWAP and cpu count configurations (some counts are estimates based on load average and percent information). For example: ) Does the change scale well to builders with 64 amd64 cpus (e.g., beefy21)? ) 96 amd64 cpus? (e.g., beefy24) ) 160 aarch64 cpus (e.g., ampere4 and ampere5 --but only 256 GiBytes of RAM each) Going along with that is the number poudriere builder process that are run in parallel and what they happen to be doing at the time. (RAM and SWAP and RAM+SWAP are not generally published or derivable from what is published by the builds.) armv7 (and non-i386 32-bit more generally) is another type of context: Also, as stands there is no official armv7 builder activity (on aarch64 with aarch32 EL0 support or on armv7 directly). So the primary source of information will be folks doing personal builds. armv7 generally limits each process to 3 GiBytes RAM+SWAP or less as I understand, including on aarch64+aarch32 hardware. For aarch64+aarch32 overall RAM+SWAP is not limited to 4 GiBytes, nor is the cpu count as limited as is common for native armv7, but on native armv7 overall RAM+SWAP is greatly limited. I expect that 32-bit powerpc is similar. None of this is an objection to trying things to find out but I'd say that it is still in an experimental stage that can only be tested live on production hardware to get the range of configurations coverage. The information available publicly for the poudriere runs on official builders is not designed to be able to track down RAM+SWAP limitations leading to OOM activity or the like. So that kind of monitoring of official builder activity will need to be done by folks with access to the relevant information. If I had known of this, I likely would have put in these kinds of notes earlier in the process. -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c0a4146e-87fa-437b-9385-c6a488d89740>