https://bugzilla.suse.com/show_bug.cgi?id=1225784 https://bugzilla.suse.com/show_bug.cgi?id=1225784#c1 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #1 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Daan De Meyer from comment #0)

In systemd when building with sanitizers we link against clang's shared ASAN libraries with -shared-libasan. The opensuse rpm we build with sanitizers is then installed into the initramfs. Currently we have to install the entire clang package into the initramfs to make sure the shared ASAN libraries are available.

Yeah, that makes sense.

Please create a compiler-rt subpackage (as exists on Fedora, CentOS and Arch Linux already) which contains the shared ASAN libraries among other things

Which other things come to mind? I presume share/*_ignorelist.txt might be interesting, maybe bin/hwasan_symbolize? But not the static libraries, right? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1225784 https://bugzilla.suse.com/show_bug.cgi?id=1225784#c5 --- Comment #5 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Daan De Meyer from comment #4)

...

Thanks for the hint! The static libraries should never be needed at runtime, so what might the reason be to put them in that package? Maybe because they're all coming from compiler-rt? Same goes for the builtin headers. But the remaining files are roughly what I'd imagine.

Yeah they all "belong" to compiler-rt in a sense. If you'd like to not have them in the compiler-rt package I would prefer having a compiler-rt-static package or so instead of keeping them in the clang package.

Why would one need them in a separate package? They shouldn't be needed at runtime, but only when building software, and I think they can only be used with Clang and not GCC. It should be noted that while compiler-rt is a separate subproject upstream, it's also upstream's choice to install it in %{_libdir}/clang.

...

What about the directory? The shared runtime libraries don't live in %{_libdir}, so without RPATH the loader won't find them.

I would again follow the other distributions here, they don't put these in %{_libdir} so I wouldn't do so in opensuse either. I currently build systemd with "-Wl,-rpath=$(clang --print-file-name="")lib/linux" when building with sanitizers to make sure the loader can find the libraries at runtime, so it's not an issue (for me) that these are not in %{_libdir}.

Instead of $(clang --print-file-name="")lib/linux, better use $(clang -print-runtime-dir). But it's not so nice that this has to be done manually, or that we need an RPATH at all. The only issue with adding SO numbers is that this is discouraged by our packaging guidelines, so I might just leave them in their directory for now. But this is also kind of against the guidelines, as these are not private libraries, but meant to be used by other applications. So they should probably live in %{_libdir}. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1225784 https://bugzilla.suse.com/show_bug.cgi?id=1225784#c9 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #9 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Daan De Meyer from comment #8)

At the same time it would also be great if the compiler-rt package explicitly added Provides for all the shared libraries so that it is automatically made a Requires of every package that is built with sanitizers enabled.

rpm -q --provides clang18 clang18 = 18.1.8-1.1 clang18(x86-64) = 18.1.8-1.1

These are added automatically, you can already see them on the clang subpackage: libclang_rt.asan-x86_64.so()(64bit) libclang_rt.dyndd-x86_64.so()(64bit) libclang_rt.hwasan-x86_64.so()(64bit) libclang_rt.hwasan_aliases-x86_64.so()(64bit) libclang_rt.memprof-x86_64.so()(64bit) libclang_rt.scudo_standalone-x86_64.so()(64bit) libclang_rt.tsan-x86_64.so()(64bit) libclang_rt.ubsan_minimal-x86_64.so()(64bit) libclang_rt.ubsan_standalone-x86_64.so()(64bit) However, as you can see they're unversioned. So you wouldn't necessarily get the right package version. The requirements don't take the directory into account. If we make the major version part of the SO name, that would change. You'd get libclang_rt.asan-x86_64.so.18()(64bit) instead of libclang_rt.asan-x86_64.so()(64bit) and zypper/rpm would make sure the right version of the package is installed. I have a local change that simply splits off the files, but I'm still thinking whether I should combine it with versioning right away or add versioning later. -- You are receiving this mail because: You are on the CC list for the bug.