Date: Tue, 19 Apr 2022 17:01:47 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 261977] lang/gcc12-devel: enable LTO Message-ID: <bug-261977-29464-Nx6KICC6xj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261977-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-261977-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261977 --- Comment #22 from Robert Clausecker <fuz@fuz.su> --- (In reply to Piotr Kubaj from comment #18) > Sure, if you insist on building manually on a slow hardware, > it's going to be painful, but we have binary packages for such users. So please tell me: which fast and affordable hardware am I supposed to test armv7 ports on then? Just let me know what the entry barrier is so I can c= heck if I can afford to continue working on the FreeBSD ports collection. Note that even cross-building doesn't help as even my Intel(R) Xeon(R) CPU E3-1270 v5 based home server takes more than 72 hours to build lang/gcc11-d= evel (after which the build was mercy-killed by Poudriere). Is this machine alr= eady considered slow hardware that no reasonable developer would compile ports o= n? What about native ARM boxes? QEMU support for armv7 sucks and many ports f= ail due to concurrency and other issues, often with terrible failure modes. So testing armv7 mostly cannot be done with QEMU. Just please let me know what the target audience is for which the build tim= es are reasonable. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261977-29464-Nx6KICC6xj>