Date: Sat, 29 Jan 2022 17:10:42 -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: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> In-Reply-To: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@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> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even >> with no swap at all on an RPi3B: >>=20 >> # 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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.) >>=20 >>=20 >> For reference . . . >>=20 >> Under main [so: 14] (UFS context example): >>=20 >> # 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 >>=20 >> Under stable/13 (ZFS and bectl context example): >>=20 >> # 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 >>=20 >> 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.) >=20 > 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: >=20 > MALLOC_PRODUCTION=3D > WITH_MALLOC_PRODUCTION=3D > WITHOUT_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D >=20 > But you report a mix of results on your systems. Might > you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. > WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your > systems where you tried the .sh on the .cpp file? >=20 > Similar points could be questioned in other buildworld > results for (implicit?) WITH_ASSERT_DEBUG=3D vs. > WITHOUT_ASSERT_DEBUG=3D 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=3D and the .sh based build of the .cpp I have still worked (no swap space active). =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?1EAE4B42-32D2-486C-BD9A-D133CF0B8293>