On Sat, Dec 6, 2025 at 9:26 PM Rozhuk Ivan <[email protected]> wrote: > > On Sat, 6 Dec 2025 19:24:33 +0200 > Konstantin Belousov <[email protected]> wrote: > > > > > > > 15.0: > > > gmake -s -j 8 19.90s user 3.02s system 773% cpu 2.96s (2.963) total > > > gmake -s -j 8 19.90s user 3.18s system 774% cpu 2.98s (2.979) total > > > gmake -s -j 8 20.24s user 2.90s system 770% cpu 3.00s (3.005) total > > > gmake -s -j 8 19.92s user 3.25s system 771% cpu 3.00s (3.003) total > > > gmake -s -j 8 20.25s user 2.95s system 772% cpu 3.01s (3.006) > > > total > > But 15.0 is definitely dynamically linked. > > > > It was super bad change for all peoples who do local compilation. > > I can not understand why FBSD Foundation does not force to revert it, it > comsumes > foundation money while they build OS and ports. > X2+ time/money for every build. > For some small ports x16+ build time (super slow on: make configure) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287447
Hello Ivan, nice to see someone was already on it, bummer it was not sorted out. Apart from reverting the offending change, one could consider going a step further and making clang statically linked in the first place. This used to be trivially achievable prior to: commit 77f6be448408eda1a31b1c98576e6c6bebf6ea6e Author: Ed Maste <[email protected]> Date: Tue Aug 1 08:48:02 2023 -0400 retire SHARED_TOOLCHAIN knob Toolchain components were historically statically linked. They became normal dynamically linked executables in commit 6ab18ea64d19. There is no need to keep a special case build option for the toolchain; users who want statically linked toolchain (or any other) components can use the existing NO_SHARED knob. I don't know how plug it it now, hopefully the commit is either trivially revertable on 14.3 or that NO_SHARED thing is easy to plug in for the compiler. That is to say, if you have time, can you please benchmark a statically linked clang vs clang which merely reverting the libprivate change? Should be a small speed up on top.
