Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled

On 2022-Jan-29, at 16:15, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Jan-28, at 22:43, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even
>> with no swap at all on an RPi3B:
>> 
>> # swapinfo
>> Device          1K-blocks     Used    Avail Capacity
>> /dev/gpt/RPi3Bswp2g   2097152        0  2097152     0%
>> # swapoff  /dev/gpt/RPi3Bswp2g
>> # swapinfo
>> Device          1K-blocks     Used    Avail Capacity
>> # ./gmock_main-f5c28a.sh
>> # ls -Tldt gmock_main-f5c28a*
>> -rw-r--r--  1 root  wheel   134840 Jan 28 22:02:09 2022 gmock_main-f5c28a.o
>> -rwxr-xr-x  1 root  wheel     4509 Jan 21 23:26:29 2022 gmock_main-f5c28a.sh
>> -rw-r--r--  1 root  wheel  7044253 Jan 21 23:26:29 2022 gmock_main-f5c28a.cpp
>> 
>> You could try such on other aarch64 RPi*'s and see if
>> any of them require swap space to do the compile. (The
>> same for any other example .cpp and .sh pairs.) My
>> expectation is that you will find that they do not
>> require any swap space be enabled.
>> 
>> This is main [so: 14] instead of stable/13 . My only
>> stable/13 environments at this point are bectl (so
>> under ZFS). I do not not try to use ZFS with less than
>> 8 GiBytes of RAM: default configuration instead of
>> tailoring for smaller amounts of RAM.
>> 
>> But I've also built under stable/13 (with ZFS involved).
>> top did not show the build of the .o using significant
>> memory under stable/13.
>> 
>> Part of the point of the .cpp that the compiler generated is that
>> it uses no include files: everything is expanded inline for
>> the source code. Thus, no other c++ source file should be involved.
>> I got the copy from where you posted it. That it builds in my
>> context indicates that it is unlikely for your or my copy of the
>> source code to be corrupted.
>> 
>> That leaves basically compiler binaries (and supporting files) as
>> potential sources of variation, possibly via corruption. (This
>> was only the production of a .o file. Fewer toolchain programs
>> are involved.)
>> 
>> 
>> For reference . . .
>> 
>> Under main [so: 14] (UFS context example):
>> 
>> # c++ -v
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
>> Target: aarch64-unknown-freebsd14.0
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> Under stable/13 (ZFS and bectl context example):
>> 
>> # c++ -v
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
>> Target: aarch64-unknown-freebsd13.0
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> So, for as much as the compiler identifies its own content, they
>> are supposedly the same, other than having a different default
>> Target FreeBSD variant. (But I do not expect that the compiler
>> identifies something unique to the combination of FreeBSD specific
>> patches or other FreeBSD choices that are involved.)
> 
> A potential source of variability in the llvm part
> of buildworld results is if LLVM assertions are
> enabled vs. disabled. My buildworlds are based, in
> part, on:
> 
> MALLOC_PRODUCTION=
> WITH_MALLOC_PRODUCTION=
> WITHOUT_ASSERT_DEBUG=
> WITHOUT_LLVM_ASSERTIONS=
> 
> But you report a mix of results on your systems. Might
> you have a mix of (implicit?) WITH_LLVM_ASSERTIONS= vs.
> WITHOUT_LLVM_ASSERTIONS= FreeBSD builds across your
> systems where you tried the .sh on the .cpp file?
> 
> Similar points could be questioned in other buildworld
> results for (implicit?) WITH_ASSERT_DEBUG= vs.
> WITHOUT_ASSERT_DEBUG= use for the builds. But this
> seems unlikely to lead to llvm-specific behavioral
> differences.


I set up and tried a context that was using
WITH_LLVM_ASSERTIONS= and the .sh based build
of the .cpp I have still worked (no swap space
active).


===
Mark Millard
marklmi at yahoo.com