From: Linus Torvalds <torvalds@linux-foundation.org>
To: Tom Stellard <tstellar@redhat.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Fangrui Song <maskray@google.com>,
        Serge Guelton <sguelton@redhat.com>,
        Sylvestre Ledru <sylvestre@mozilla.com>
Subject: Re: Very slow clang kernel config ..
Date: Sat, 1 May 2021 09:32:25 -0700
Message-ID: <CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com> (raw)
In-Reply-To: <1c5e05fa-a246-9456-ff4e-287960acb18c@redhat.com>

On Fri, Apr 30, 2021 at 8:33 PM Tom Stellard <tstellar@redhat.com> wrote:
>
> Yes, it's intentional.  Dynamic linking libraries from other packages is
> the Fedora policy[1], and clang and llvm are separate packages (in Fedora).

Side note: I really wish Fedora stopped doing that.

Shared libraries are not a good thing in general. They add a lot of
overhead in this case, but more importantly they also add lots of
unnecessary dependencies and complexity, and almost no shared
libraries are actually version-safe, so it adds absolutely zero
upside.

Yes, it can save on disk use, but unless it's some very core library
used by a lot of things (ie particularly things like GUI libraries
like gnome or Qt or similar), the disk savings are often not all that
big - and disk is cheap. And the memory savings are often actually
negative (again, unless it's some big library that is typically used
by lots of different programs at the same time).

In this case, for example, it's true that a parallel build will be
running possibly hundreds of copies of clang at the same time - and
they'll all share the shared llvm library. But they'd share those same
pages even if it wasn't a shared library, because it's the same
executable! And the dynamic linking will actually cause a lot _less_
sharing because of all the fixups.

We hit this in the subsurface project too. We had a couple of
libraries that *nobody* else used. Literally *nobody*. But the Fedora
policy meant that a Fedora package had to go the extra mile to make
those other libraries be shared libraries, for actual negative gain,
and a much more fragile end result (since those libraries were in no
way compatible across different versions - so it all had to be updated
in lock-step).

I think people have this incorrect picture that "shared libraries are
inherently good". They really really aren't. They cause a lot of
problems, and the advantage really should always be weighed against
those (big) disadvantages.

Pretty much the only case shared libraries really make sense is for
truly standardized system libraries that are everywhere, and are part
of the base distro.

[ Or, for those very rare programs that end up dynamically loading
rare modules at run-time - not at startup - because that's their
extension model. But that's a different kind of "shared library"
entirely, even if ELF makes the technical distinction between
"loadable module" and "shared library" be a somewhat moot point ]

https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/
--
FROM 112.47.122.*

赞成。shared code比shared lib好用得多。  
  
【 在 hgoldfish (老鱼) 的大作中提到: 】
:  From: Linus Torvalds <torvalds@linux-foundation.org>
:  To: Tom Stellard <tstellar@redhat.com>
:  Cc: Nick Desaulniers <ndesaulniers@google.com>,
:          Masahiro Yamada <masahiroy@kernel.org>,
--
FROM 183.128.130.*

节省编译时间不好吗？ 特别是对C++这种编译慢的要死的语言。。。
--
FROM 1.91.32.*

按 linus 的意思是。。除了 glibc，其它的都应该静态链接？

我自己在使用 qt 的时候，也都倾向于静态链接。

【 在 ilovecpp (cpp) 的大作中提到: 】
: 他可以用snap。就像他希望的，gnome和qt还是共享，其它依赖一般和应用打包在一起了。
--
FROM 140.224.34.*

【 在 hgoldfish 的大作中提到: 】
: 按 linus 的意思是。。除了 glibc，其它的都应该静态链接？
: 我自己在使用 qt 的时候，也都倾向于静态链接。
:
我们的几个项目之前也是动态链接，后来core了 debug超级麻烦，就改回静态链接了
--
FROM 221.192.180.*