Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?
- Reply: Michal Meloun : "Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?"
- Reply: Mark Millard : "Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?"
- In reply to: Mark Millard : "Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 04 Aug 2024 21:31:46 UTC
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: > > 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=1 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 == 1958Mi+3685Mi == 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 == 31311Mi+120831Mi == 152142Mi > > So lots of 4 GiByte or smaller processes would fit. > Absent finding a way to get --threads=1 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 = hardware_concurrency(threads); config->thinLTOJobs = v; + } else if (sizeof(void*) <= 4) { + log("set maximum concurrency to 1, specify --threads= to change"); + parallel::strategy = hardware_concurrency(1); } else if (parallel::strategy.compute_thread_count() > 16) { log("set maximum concurrency to 16, specify --threads= to change"); parallel::strategy = 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. === Mark Millard marklmi at yahoo.com