Date: Mon, 8 Dec 2025 03:51:05 +0200 From: Rozhuk Ivan <rozhuk.im@gmail.com> To: Konstantin Belousov <kib@freebsd.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, Warner Losh <imp@bsdimp.com>, Mark Millard <marklmi@yahoo.com>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, brooks@FreeBSD.org Subject: Re: performance regressions in 15.0 Message-ID: <20251208035105.2313075d@rimwks.local> In-Reply-To: <aTYYpcYm8uOU1M_q@kib.kiev.ua> References: <EF95C136-B1D2-4820-A069-D0078A3B5A05@yahoo.com> <18FB2858-5CBB-4B7A-8089-224A58C6A160@yahoo.com> <CANCZdfqfXfzGQRN5TR7KFcNE1-Ng4ECFKD_6V0118b2UwwX09Q@mail.gmail.com> <CAGudoHEztjmAb2uxRYK-CDjUBx6kEoeKDUgF8R4UvhoNp3A4_w@mail.gmail.com> <aTYYpcYm8uOU1M_q@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20251208035105.2313075d>