Date: Thu, 07 Oct 2021 08:06:39 UTC
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.