Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jan 2022 22:43:39 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        Free BSD <freebsd-arm@freebsd.org>
Subject:   Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled
Message-ID:  <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com>
In-Reply-To: <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com>
References:  <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F856AEE-F580-4578-BA45-16849769AD18>