Re: performance regressions in 15.0

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)
	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!!!

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.