From: Miguel Ojeda <firstname.lastname@example.org>
To: David Laight <David.Laight@aculab.com>
Cc: Adrian Bunk <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
Tom Stellard <email@example.com>,
Nick Desaulniers <firstname.lastname@example.org>,
Masahiro Yamada <email@example.com>,
Nathan Chancellor <firstname.lastname@example.org>,
Linux Kernel Mailing List <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: Wed, 5 May 2021 18:06:44 +0200 [thread overview]
Message-ID: <CANiq72kPx48wTKCfgohwb2CbAf=SG3gyhv3htd3n_17aGAq2FA@mail.gmail.com> (raw)
On Wed, May 5, 2021 at 4:13 PM David Laight <David.Laight@aculab.com> wrote:
> Many years ago the company I worked for found that the unix 'utmpx'
> file was getting corrupted (due to incorrect locking).
> The functions had been places in an archive part of libc (for
> various reasons).
> Getting the fix onto the customers machine (we were the OS vendor)
> involved determining which applications from 3rd (4th?) parties
> had been linked with the broken code and then applying enough
> 'gentle persuasion' to get them to relink the offending programs.
> Even this can be problematic because the source control systems
> of some companies isn't great (it is probably better these days).
> But getting the 'previous version' rebuilt with a new libc.a
> can be very problematic.
If you are a library vendor and you provide the fixed library, then
you are done. It is your customer's call to rebuild their software or
not; and they are the ones choosing static linking or not.
Sure, you want to offer the best service to your clients, and some
customers will choose static linking without fully understanding the
pros/cons, but you cannot do anything against that. And you still need
to provide the static version for those clients that know they need
> No because there are messages sent to system daemons and file
> formats that can be system dependant.
> Not everything is a system call.
That is orthogonal to static linking or not, which was the topic at hand.
What you are talking about now are dependencies on external entities
and services. Static linking is not better nor worse just because you
depend on a local process, a file, a networked service, a particular
piece of hardware being present, etc.
> Remind be to request our management to let me remove all the C++
> from most of our programs.
Yeah, the problem exists since before 1998 :)
A stable, common C++ ABI etc. would have had some advantages, but it
did not happen.
> None of them actually need it, the reasons for C++ aren't technical.
Well, no program "needs" any particular language, but there are
advantages and disadvantages of using languages with more features
(and more complexity, too). It is a balance.
For the kernel, we believe Rust brings enough advantages over *both* C
and C++ to merit using it. C++ also has advantages over C, but it has
a big complexity burden, it has not had the luxury of being designed
from scratch with decades of hindsight from C and C++ like Rust has
had, and it does not have a UB-free subset.
> That sounds like it has all the same problems as pre-compiled headers.
PCHs are a hack to improve build times, yes.
In Rust, however, it is a more fundamental feature and the needed
information goes encoded into your library (.rlib, .so...).
next prev parent reply other threads:[~2021-05-05 16:07 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 21:53 Very slow clang kernel config 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
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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).