RE: Very slow clang kernel config ..

[David Laight <David.Laight@ACULAB.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)