Re: libc build failure

[Igor Khavkine]

On Tue, Aug 21, 2001 at 05:24:03PM -0400, Roland McGrath wrote:
> > 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?
> 
> The elements you are overlooking are the reasons `extern inline' was
> invented in the first place.  In unoptimized code, a real static function
> is generated in each and every .o file that included the header file,
> whether or not it used the function.  That is a big difference.  If you are
> optimizing and you use `static inline', you get unused function warnings in
> every file that uses the header but not the function.  (At the time `extern
> inline' was invented, there was no __attribute__ concept at all, so you
> couldn't use __attribute__((unused)) as you could now.)
> 
> Neal only had a problem because there was a bug in the use of extern inline
> in libc.  When using extern inline, you have to know what you are doing and
> do it properly.

Actually, GCC does exactly what it says in the documentation. Even if
not optimizing (-O0) unless `static inline' functions are referenced
in some way (called or the function pointer is used somewhere) it is
not output in the object code (checked with objdump -d). Maybe this was
not true with older compilers, but I've just tested it with gcc-2.95.4.

Igor