Re: performance regressions in 15.0

On Mon, Dec 08, 2025 at 03:51:05AM +0200, Rozhuk Ivan wrote:
> On Mon, 8 Dec 2025 02:15:33 +0200
> Konstantin Belousov <kib@freebsd.org> wrote:
> 
> > Next, the change of llvm components to dynamically link with the llvm
> > libs is how upstream does it.  Not to mention, that this way to use
> > clang+lld saves both disk space (not very important) and memory (much
> > more important).
> 
> It waste time and energy = money waster, "multiply CO2 production".
> And there is nothing good to user to pay this price.
> 
> 
> I have:
> 
> # pkg version -vI | grep llvm
> libclc-llvm15-15.0.7               =   up-to-date with index
> llvm15-15.0.7_10                   =   up-to-date with index
> llvm17-17.0.6_8                    =   up-to-date with index
> llvm18-18.1.8_2                    =   up-to-date with index
> llvm19-19.1.7_1                    =   up-to-date with index
> 
> there is no any crappy libprivateclang.so/libprivatellvm.so shared libs:
> 
> # ldd /usr/local/llvm19/bin/clang-19
> /usr/local/llvm19/bin/clang-19:
> 	libthr.so.3 => /lib/libthr.so.3 (0x801063000)
> 	libclang-cpp.so.19.1 => /usr/local/llvm19/bin/../lib/libclang-cpp.so.19.1 (0x801200000)
> 	libLLVM.so.19.1 => /usr/local/llvm19/bin/../lib/libLLVM.so.19.1 (0x805c00000)
Did you noted this line?

> 	libc++.so.1 => /lib/libc++.so.1 (0x801092000)
> 	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80119b000)
> 	libm.so.5 => /lib/libm.so.5 (0x8011bd000)
> 	libc.so.7 => /lib/libc.so.7 (0x80d663000)
> 	librt.so.1 => /lib/librt.so.1 (0x805bcb000)
> 	libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x805bd4000)
> 	libz.so.6 => /lib/libz.so.6 (0x805bda000)
> 	libzstd.so.1 => /usr/local/lib/libzstd.so.1 (0x80d963000)
> 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80da38000)
> 	libelf.so.2 => /lib/libelf.so.2 (0x80da59000)
> 	[vdso] (0x7ffffffff000)
> 
> But 
> # ls /usr/bin/cc
> -r-xr-xr-x  6 root wheel   82M Oct 19 18:10:39 2025 /usr/bin/cc*
> # ls /usr/local/llvm19/bin/clang-19
> -rwxr-xr-x  2 root wheel  125K Aug 18 06:43:31 2025 /usr/local/llvm19/bin/clang-19*
> So it dynamic linked....
> ....
> And we found in port:
> CMAKE_ARGS=	-DLLVM_BUILD_LLVM_DYLIB=ON
> CMAKE_ARGS+=	-DLLVM_LINK_LLVM_DYLIB=ON
> (exist from first llvm6 372b8a151352984140f74c342a62eae2236b2c2c and copy-pasted to all next llvm~s by brooks@FreeBSD.org)
> 
> According to: https://llvm.org/docs/CMake.html
> =============================================================================================
> BUILD_SHARED_LIBS is only recommended for use by LLVM developers.
> If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.
> =============================================================================================
> 
> So upstream DOES NOT RECOMMEND to build shared libs to users!!!
I am curious about the motivation.

JFYI, shared llvm libs are required for lot of things.  The incomplete
list of examples that I am aware of are dri drivers and ispc Intel compiler.

> 
> Why FBSD use shared libs for LLVM in ports and now in base!???
> 
> @brooks - why do you do that?
> 
> 
> > The implied load on rtld is something that could be handled: there is
> > definitely no need to have such huge surface of exported symbols on
> > both libllvm and esp. libclang. Perhaps by default the internal
> > libraries can use protected symbols, normally C++ do not rely on
> > interposing. But such 'fixes' must occur at upstream.
> > 
> > So far all the clang toolchain changes were aligning it with what the
> > llvm project does.
> > 
> 
> No, upstream does not recommend to use shared libs to llvm users.