From: David Laight <David.Laight@ACULAB.COM> To: 'Miguel Ojeda' <email@example.com> Cc: Adrian Bunk <firstname.lastname@example.org>, Linus Torvalds <email@example.com>, 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: Wed, 5 May 2021 16:25:45 +0000 [thread overview] Message-ID: <42fdc9f1b4b44136b4eeffa0957ebc3e@AcuMS.aculab.com> (raw) In-Reply-To: <CANiq72kPx48wTKCfgohwb2CbAf=SG3gyhv3htd3n_17aGAq2FA@mail.gmail.com> From: Miguel Ojeda > Sent: 05 May 2021 17:07 > > 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. But it is the customer's customer who comes back to you saying that something in your library is broken. This is when you really don't what static linking - ever. > 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 > it. > > > 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. Static linking is much worse because different parts of the 'system' are provided by different people. With a little care a C shared library can be implemented by different companies while still meeting the same ABI. > > 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. It this case it was done to give the software engineers some experience of writing C++. Technically it was a big mistake. Bad C++ is also infinitely worse that bad C. Exception handling (which you might think of as a gain) is very easy to get badly wrong. Class member overloads make it impossible to work out where data is used. Function overloads are sometimes nice - but unnecessary. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-05-05 16:25 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 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 [this message] 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=42fdc9f1b4b44136b4eeffa0957ebc3e@AcuMS.aculab.com \ --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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).