Date: Sun, 4 Aug 2024 14:31:46 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? Message-ID: <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> In-Reply-To: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 3, 2024, at 23:07, Mark Millard <marklmi@yahoo.com> wrote:
> 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:
>=20
> LLVM ERROR: out of memory
> Allocation failed
>=20
> (no system OOM activity or notices, so just a process =
size/fragmentation issue, or so I would expect).
>=20
> On native armv7 I also had rust 1.79.0 fail that way so --but =
aarch64-as-armv7 built it okay.
>=20
> 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.)
>=20
> 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.
>=20
>=20
> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had
> at boot time:
>=20
> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi
>=20
> and later had "Max(imum)Obs(erved)" figures:
>=20
> Mem: . . .,
> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi =
MaxObs(Act+Wir+Lndry)
>=20
> Swap: 3685Mi Total, . . .,
> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed),
> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct)
>=20
>=20
> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and:
>=20
> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi
>=20
> So lots of 4 GiByte or smaller processes would fit.
>=20
Absent finding a way to get --threads=3D1 to be what is used, I
made the following crude way to test, built it, installed it
in the armv7 directory tree used for aarch64-as-armv7, and
then started an aarch64-as-armv7 test of building devel/llvm19
to see what the consequences are (leading whitespace details
might not be preserved):
# git -C /usr/main-src/ diff contrib/llvm-project/
diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp =
b/contrib/llvm-project/lld/ELF/Driver.cpp
index 8b2c32b15348..299daf7dd6fa 100644
--- a/contrib/llvm-project/lld/ELF/Driver.cpp
+++ b/contrib/llvm-project/lld/ELF/Driver.cpp
@@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList &args) {
arg->getValue() + "'");
parallel::strategy =3D hardware_concurrency(threads);
config->thinLTOJobs =3D v;
+ } else if (sizeof(void*) <=3D 4) {
+ log("set maximum concurrency to 1, specify --threads=3D to =
change");
+ parallel::strategy =3D hardware_concurrency(1);
} else if (parallel::strategy.compute_thread_count() > 16) {
log("set maximum concurrency to 16, specify --threads=3D to =
change");
parallel::strategy =3D hardware_concurrency(16);
Basically, if the process address space has to be "small", avoid
any default memory use tradeoffs that multi-threading the linker
might involve --even if that means taking more time.
We will see if:
[00:00:33] [07] [00:00:00] Building devel/llvm19@default | =
llvm19-19.1.0.r1
still fails to build as armv7 vs. if the change leads it to
manage to build as armv7.
=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?82E78798-C376-45C4-80FE-96AD14229419>