From: Adrian Bunk <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: Tom Stellard <firstname.lastname@example.org>, Nick Desaulniers <email@example.com>, Masahiro Yamada <firstname.lastname@example.org>, Nathan Chancellor <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, clang-built-linux <email@example.com>, Fangrui Song <firstname.lastname@example.org>, Serge Guelton <email@example.com>, Sylvestre Ledru <firstname.lastname@example.org> Subject: Re: Very slow clang kernel config .. Date: Mon, 3 May 2021 00:48:04 +0300 [thread overview] Message-ID: <20210502214803.GA7951@localhost> (raw) In-Reply-To: <CAHk-=whTjJwCt2E0_JM2dDq=+UybvJN7QK+6K6e80A9Zd8duYg@mail.gmail.com> On Sun, May 02, 2021 at 10:59:10AM -0700, Linus Torvalds wrote: > On Sun, May 2, 2021 at 10:55 AM Adrian Bunk <email@example.com> 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
next prev parent reply other threads:[~2021-05-02 21:48 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-29 21:53 Linus Torvalds 2021-04-30 0:19 ` Nick Desaulniers 2021-04-30 2:22 ` Nick Desaulniers 2021-05-01 0:19 ` Nick Desaulniers 2021-05-01 0:23 ` Nick Desaulniers 2021-05-01 0:25 ` Nick Desaulniers 2021-05-01 0:40 ` Nick Desaulniers 2021-05-01 1:22 ` Linus Torvalds 2021-05-01 1:48 ` Nick Desaulniers 2021-05-01 2:16 ` Fangrui Song 2021-05-01 3:32 ` Tom Stellard 2021-05-01 16:32 ` Linus Torvalds 2021-05-01 19:57 ` Serge Guelton 2021-05-01 22:39 ` Linus Torvalds 2021-05-01 23:55 ` Fangrui Song 2021-05-01 21:58 ` David Laight 2021-05-02 9:31 ` Adrian Bunk 2021-05-02 11:35 ` David Laight 2021-05-02 16:12 ` Linus Torvalds 2021-05-02 16:45 ` Adrian Bunk 2021-05-02 16:49 ` Linus Torvalds 2021-05-02 17:55 ` Adrian Bunk 2021-05-02 17:59 ` Linus Torvalds 2021-05-02 21:48 ` Adrian Bunk [this message] 2021-05-04 22:02 ` Miguel Ojeda 2021-05-05 0:58 ` Theodore Ts'o 2021-05-05 17:21 ` Miguel Ojeda 2021-05-04 21:32 ` Miguel Ojeda 2021-05-05 11:05 ` David Laight 2021-05-05 13:53 ` Miguel Ojeda 2021-05-05 14:13 ` David Laight 2021-05-05 16:06 ` Miguel Ojeda 2021-05-05 16:25 ` David Laight 2021-05-05 17:55 ` Miguel Ojeda 2021-05-03 1:03 ` Maciej W. Rozycki 2021-05-03 14:38 ` Theodore Ts'o 2021-05-03 14:54 ` Theodore Ts'o 2021-05-03 17:14 ` Maciej W. Rozycki 2021-05-03 16:09 ` David Laight 2021-05-04 23:04 ` Greg Stark 2021-05-05 0:55 ` Theodore Ts'o 2021-05-01 23:37 ` Mike Hommey 2021-05-02 5:19 ` Dan Aloni 2021-05-03 16:48 ` Tom Stellard 2021-05-03 19:00 ` Fangrui Song 2021-04-30 0:52 ` Nathan Chancellor 2021-04-30 2:21 ` Nick Desaulniers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210502214803.GA7951@localhost \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Very slow clang kernel config ..' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).