Re: libc build failure

[Igor Khavkine]

Roland McGrath wrote:
> 
> The use of extern inline is not a mistake.  You don't seem to know what
> it's for; read the GCC manual's `Inline' section.

I've read that section, and that's why I raised this point in the first
place. Here are the relevant portions of the manual:

     When a function is both inline and `static', if all calls to the
  function are integrated into the caller, and the function's address is
  never used, then the function's own assembler code is never referenced.
  In this case, GCC does not actually output assembler code for the
  function, unless you specify the option `-fkeep-inline-functions'.

  [...]

     If you specify both `inline' and `extern' in the function
  definition, then the definition is used only for inlining.  In no case
  is the function compiled on its own, not even if you refer to its
  address explicitly.

  [...]

     This combination of `inline' and `extern' has almost the effect of a
  macro.  The way to use it is to put a function definition in a header
  file with these keywords, and put another copy of the definition
  (lacking `inline' and `extern') in a library file.

  [...]

     For future compatibility with when GCC implements ISO C99 semantics
  for inline functions, it is best to use `static inline' only.

Both static and extern functions will can be put into header files so they
can be used instead of macros. However if static is used, it avoids the
kind of problems Neal has been having. The only difference is that the
non-inlined copy of the function will be linked to the C library (for extern
of a non-inlined copy exists) or to the program's that's including the header
object code. Is this really such a big difference?

I'm not the only one concerned about this, the Linux kernel code used to use
`extern inline' now they are also using `static inline' in many cases.

Igor