Date: Sat, 3 Aug 2024 23:07:59 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? Message-ID: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My recent attempts to build devel/llvm18 and devel/llvm19 in an armv7 = context (native or aarch64-as-armv7) have had /usr/bin/ld failures that = stop the build and report as: LLVM ERROR: out of memory Allocation failed (no system OOM activity or notices, so just a process size/fragmentation = issue, or so I would expect). On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) Note: The structure of the poudriere-devel based native build attempts = is historical and it used to work. Similarly for the aarch64-as-armv7 = based build attempts. For now I'd just be exploring changes that might = allow much of my historical overall structure to still work. But I = expect that things are just growing to the point building is starting to = be problematical with process address spaces that are bounded by a limit = somewhat under 4 GiBytes. Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had at boot time: AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi and later had "Max(imum)Obs(erved)" figures: Mem: . . ., 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi MaxObs(Act+Wir+Lndry) Swap: 3685Mi Total, . . ., 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi So lots of 4 GiByte or smaller processes would fit. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FFD603F-E67C-4B62-B91B-8BE365EAA050>