Date: Sat, 29 Jan 2022 16:15:18 -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: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> In-Reply-To: <2F856AEE-F580-4578-BA45-16849769AD18@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=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.) 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=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D 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? 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. =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?3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B>