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

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.


===
Mark Millard
marklmi at yahoo.com