On 10/7/21 3:18 AM, Mark Millard via freebsd-ports wrote:
Piotr Kubaj <pkubaj_at_anongoth.pl> wrote on
Date: Tue, 5 Oct 2021 22:41:38 +0200 :
But I agree that building everything with LTO may require memory upgrades
for builders. The extreme example is mongodb (has an LTO option enabled by
default) which allocates close to 30GB RAM during linking.
Sounds like armv7, armv6, and 32-bit powerpc variants will likely not
get lto use by default: process size limits in native contexts (including
the likes of AArch32 mode with AArch64 when supported). Hand tailoring
all the ports for platform specifics would likely be too much.
Separately from that, my two contexts that I have access to that use
USE_TMPFS=all and ALLOW_MAKE_JOBS= for bulk -a (rarely run unless
experimenting) might not have sufficient RAM+SWAP for LTO mode
without other poudriere-devel configuration changes:
16 FreeBSD cpu aarch64 (HoneyComb) (also used for builds targeting armv7)
32 FreeBSD cpu amd64 (ThreadRipper 1950X)
[The SWAPs are set near where adding more swap would start to complain
about mistuning. Upgrading to more RAM on the HoneyComb is not possible
(64 GiByte). Upgrading to more RAM on the ThreadRipper 1950X is not
possible (128 GiByte).]
I'm more likely to want to have poudreire-devel not use a general
LTO-enabled mode and keep USE_TMPFS and ALLOW_MAKE_JOBS as I do now
for bulk -a .
I do not do bulk -a on any of the smaller/slower ssystems that I have
access to (aarch64 and armv7). But I still use poudriere-devel to
build some packages on them sometimes. It sounds like I'd not use LTO
in those contexts either.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Hi,
My RPi4 has OPTIONS_UNSET+=LTO in /etc/make.conf and I configured that in my
poudriere builds also. (As maintainer of some of the mongodb ports.) Even on
the official pkg build clusters mongodb fails to build now and than with LTO
enabled. I presume that happens when multiple big builds run together. But
followup builds succeed again, so no big harm (yet).
Regards,
Ronald.
