linux-kernel - Re: Very slow clang kernel config ..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210502214803.GA7951@localhost>
Date:   Mon, 3 May 2021 00:48:04 +0300
From:   Adrian Bunk <bunk@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Tom Stellard <tstellar@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Fangrui Song <maskray@...gle.com>,
        Serge Guelton <sguelton@...hat.com>,
        Sylvestre Ledru <sylvestre@...illa.com>
Subject: Re: 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@...nel.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