(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}.