Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build?

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.

===
Mark Millard
marklmi at yahoo.com