Bugzilla – Bug 1225784
clang: Please subpackage compiler-rt libraries
Last modified: 2024-07-13 09:34:01 UTC
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. Please create a compiler-rt subpackage (as exists on Fedora, CentOS and Arch Linux already) which contains the shared ASAN libraries among other things so we don't have to install the full clang package into the initramfs when building with sanitizers.
(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?
I would follow what the other distros do here. Both Fedora and Arch Linux do include the static libraries (https://fedora.pkgs.org/40/fedora-x86_64/compiler-rt-18.1.1-1.fc40.x86_64.rpm.html) so I would do the same in OpenSUSE.
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. What about the directory? The shared runtime libraries don't live in %{_libdir}, so without RPATH the loader won't find them. If I put them in %{_libdir}, we have problems with multiple versions. And I don't know if the runtimes have ABI stability guarantees, i.e. can you run an application compiled with clang17 with compiler-rt18? Otherwise I might have to add some kind of SO version, something like (lib)compiler-rt%{_sonum}: %{_libdir}/libclang_rt.asan-x86_64.so.%{_soname} clang%{_sonum}: %{_libdir}/clang/%{_sonum}/lib/libclang_rt.asan-x86_64.so -> %{_libdir}/libclang_rt.asan-x86_64.so.%{_soname} What do you think?
> 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. I'm not sure what the opensuse packaging guidelines have to say about this though. > 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}.
(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}.
> 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. Both are fine with me, I don't mind too much where the static libraries live, as long as the shared libraries are subpackaged. > Instead of $(clang --print-file-name="")lib/linux, better use $(clang -print-runtime-dir). Thank you for the suggestion, I will give that a try. > 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}. Frankly if you did this it would just make my life harder. Every other distro ships these libraries in the private directory so I'd just have to add yet more special casing to deal with openSUSE doing it differently. If you really want to go this route I would suggest discussing this with all the other distribution clang maintainers so this move can be done across distros instead of only in openSUSE. Given the amount of work that would entail, I suggest just following the other distributions here.
(In reply to Daan De Meyer from comment #6) > Frankly if you did this it would just make my life harder. That isn't the intention. The plan would be to keep the libraries in the runtime directory and add symlinks from %{_libdir} or the other way around. Either way, since the Clang driver looks for the libraries in the runtime directory, they would need to stay there of course. So everything that works on other distros should also work on openSUSE. > I would suggest discussing this with all the other distribution clang > maintainers so this move can be done across distros instead of only in > openSUSE. Of course. Also notable that GCC puts their runtime libraries in %{_libdir}, although they have an SO version from upstream already.
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.