lkml.org 
[lkml]   [2021]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Very slow clang kernel config ..
On Sun, May 02, 2021 at 10:59:10AM -0700, Linus Torvalds wrote:
> On Sun, May 2, 2021 at 10:55 AM Adrian Bunk <bunk@kernel.org> wrote:
> >
> > Are you happy about libclang.so being a shared library?
>
> Honestly, considering how I don't have any other package that I care
> about than clang itself, and how this seems to be a *huge* performance
> problem, then no.
>
> But you are still entirely avoiding the real issue: the Fedora rule
> that everything should be a shared library is simply bogus.

It is not a Fedora-specific rule, we have something similar in Debian.

And in general, static libraries in the C/C++ ecosystem often feel like
a rarely used remnant from the last millenium (except for convenience
libraries during the build).

> Even if the llvm/clang maintainers decide that that is what they want,
> I know for a fact that that rule is completely the wrong thing in
> other situations where people did *not* want that.

libdivecomputer is now a submodule of subsurface.

If this is the only copy of libdivecomputer in a distribution,
then linking subsurface statically with it and not shipping it
as a separate library at all is fine for distributions.

The Fedora policy that was linked to also states that this is OK.

The important part for a distribution is to ship only one copy of the
code and having to rebuild only the one package containing it when
fixing a bug.

> Can you please stop dancing around that issue, and just admit that the
> whole "you should always use shared libraries" is simply WRONG.
>
> Shared libraries really can have huge downsides, and the blind "shared
> libraries are good" standpoint is just wrong.

Good for distributions or good for performance?

These two are quite distinct here, and distribution rules care about
what is good for distributions.

Library packages in ecosystems like Go or Rust are copies of the source
code, and when an application package is built with these "libraries"
(might even be using LTO) this is expected to be faster than using
shared libraries.

But for distributions not using shared libraries can be a huge pain.

Compared to LTO compilation of all code used in an application, static
linking gives the same pain to distributions with smaller benefits.

I agree that on the performance side you have a valid point regarding
the disadvantages of shared libraries, but not using them is bad for
distributions since it makes maintaining and supporting the software
much harder and security support often impossible.

> Linus

cu
Adrian

\
 
 \ /
  Last update: 2021-05-02 23:48    [W:0.054 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site