On Mon, 8 Dec 2025 02:15:33 +0200
Konstantin Belousov <[email protected]> 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 [email protected])
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.
