Re: llvm10 build failure on Rpi3
- In reply to: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 24 Jun 2021 01:29:30 UTC
On 2021-Jun-23, at 18:15, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Jun-23, at 17:58, Mark Millard <marklmi at yahoo.com> wrote: > >> Misc notes . . . >> >> Looking at your logs, I expect trying to build both >> llvm10 and rust in parallel is likely to run into >> resource issues on teh RPi3B+. For builds in that >> context, it may be better to do something like: >> >> # poudriere buld -j main devel/llvm10 >> # poudriere buld -j main lang/rust >> # poudriere buld -j main -f SOMEFILE-LISTING-OTHER-ORIGINS >> >> based on using ALLOW_MAKE_JOBS=yes . >> >> Part of this I based on your on-going llvm10-10.0.1_5 >> build shows load averages (example): >> >> 4.53 4.49 4.40 >> >> so all 4 cores are busy with a little backlogged work >> already. It is also part of the explanation for: >> >> bad_C++_code 24:30:53 for both building at the same time >> vs. >> bad_C++_code 06:59:12 for only llvm10 building. >> >> (I'm not making claims for overall elapsed time.) >> >> You wrote in http://www.zefox.org/~bob/readme : >> >> MAX_EXECUTION_TIME_PACKAGE=432000 (since increased to 1724000, builds still stop at 24 hours) >> >> I think you may have guessed wrong about what >> MAX_EXECUTION_TIME_PACKAGE covers: it is for >> after staging the build, just creating the package >> from the staged material. It is not for the >> overall time turning the port into a package. >> >> The time to build (through staging?) is controlled >> by something you have left commented out and have >> not adjusted: >> >> # This defines the max time (in seconds) that a command may run for a build >> # before it is killed for taking too long. Default: 86400 >> #MAX_EXECUTION_TIME=86400 >> >> My prior notes had listed: >> >> # Cortex-A53 and such are slow for the purpose, allow 4 times the defaults: >> MAX_EXECUTION_TIME=432000 >> >> But the figures that I'd used never dealt with something like >> rust on something like an RPi3B+. So the figure may well be >> too small even if rust is never built in parallel with anything >> else. (A similar point goes for all my example MAX_EXECUTION_TIME* >> figures.) I did do various llvm* builds, but rust is bigger than >> any one of those by a long shot. >> >> Parallel builds of things like llvm10 and rust in significantly >> overlapping time frames put the load average well over 4 and >> likely cause periods if significant paging/swapping. This can >> greatly expand the elapsed-time for the individual jobs (builders). >> >> > > Just adding another note. > > QUOTE > /usr/src contains a finished > buildworld. /usr/ports contains a recently-updated ports tree. > > # cd /usr/src > # make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > # make distrib-dirs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > # make distribution DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > END QUOTE > > In the above, /usr/local/poudriere/poudriere-system/ ends up containing > a finished buildworld, instead of /usr/src/ containing such. ( /usr/src/ > was put to use to do the build. ) > Yet another note: http://www.zefox.org/~bob/ lists: /etc/make.conf But that is the wrong place for a poudriere make.conf . One possibility for a poudriere.d make.conf is: /usr/local/etc/poudriere.d/make.conf But nothing published indicates that you have such. (There are names with a -make.conf suffix that are also possible.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)