Re: Restarting poudriere
- Reply: Mark Millard via freebsd-ports : "Re: Restarting poudriere"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 14 Jun 2021 19:03:25 UTC
bob prohaska <fbsd_at_www.zefox.net> wrote on Date: Mon, 14 Jun 2021 09:28:39 -0700 : > Thanks to much support on the lists it looks like poudriere _almost_ > worked on the Pi3. I'm presuming the RPi3B+ is being used as aarch64 instead of armv7. > In earlier tries builds of llvm10 failed from lack of memory. Restraining > poudriere with -J 2 and MAKE_JOBS_NUMBER=2 in /etc/make.conf, along with > turning off use of tmpfs appears to have relieved the excess memory pressure. > > Restarting the poudriere session still fails with llvm10, reporting > > c++: error: no such file or directory: '/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp' > c++: error: no input files > ninja: build stopped: subcommand failed. > *** Error code 1 > > Similarly, the build of rust stopped with > > 10: fatal error: 'PPCTargetMachine.h' file not found > #include "PPCTargetMachine.h" > ^~~~~~~~~~~~~~~~~~~~ > 1 error generated. > ninja: build stopped: subcommand failed. > thread 'main' panicked at ' > command did not execute successfully, got: exit code: 1 > > It looks like artifacts from the previous build failures are somehow > persisting into subsequent work. poudriere does not do that. Each builder (job) is started from scratch, only reusing already built packages (via reinstallation in the temporary jail). That includes its jail-local /wrkdirs/. . . content being built up from scratch (from distribution files). > There are no indications of memory > or swap insufficiency. > > Can anybody suggest a fix, short of starting over from scratch? > Perhaps building the offending packages individually, or in separate > jails? I've been using the same jail for all attempts so far. I will note that on arm (aarch64 and armv7) I use: # more /usr/local/etc/poudriere.d/options/devel_llvm10/options # This file is auto-generated by 'make config'. # Options for llvm10-10.0.1_3 _OPTIONS_READ=llvm10-10.0.1_3 _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=BE_AMDGPU OPTIONS_FILE_SET+=CLANG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXTRAS OPTIONS_FILE_SET+=LIT OPTIONS_FILE_SET+=LLD OPTIONS_FILE_SET+=LLDB OPTIONS_FILE_SET+=LLD_LINK OPTIONS_FILE_SET+=OPENMP OPTIONS_FILE_UNSET+=PYCLANG OPTIONS_FILE_UNSET+=BE_FREEBSD OPTIONS_FILE_SET+=BE_NATIVE OPTIONS_FILE_UNSET+=BE_STANDARD in part in order to avoid building for targeting non-arm architectures. So: no Hexagon or powerpc* . (Less time wasted in my context.) Because of that use, I'm unsure if I would get the same as you report from using BE_FREEBSD or BE_STANDARD instead on aarch64. It is possible to have poudriere produce a (compressed) tar of the /wrkdirs/usr/ports/devel/llvm10/work/ content that can later be extracted someplace and looked at. Producing these for llvm10 tends to take significant time once it starts. The files are put at paths that look like: /usr/local/poudriere/data/wrkdirs/JAILNAME/default/* Depending on your poudriere.conf content, you might already have such a compressed tar. But I'm not sure that you would want to see what was under: . . ./llvm-10.0.1.src/lib/Target/Hexagon/. . . or if . . ./llvm-10.0.1.src/lib/Target/Hexagon/ even exists. (I'm not sure what you would do with the information beyond reporting it.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)