This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: using glibc2.1 with compiler other than gcc: Problems
- To: drepper@cygnus.com (Ulrich Drepper)
- Subject: Re: using glibc2.1 with compiler other than gcc: Problems
- From: Roland McGrath <roland@marker.cs.utah.edu>
- Date: Tue, 28 Jul 1998 18:51:09 -0600 (MDT)
- Cc: Andreas Jaeger <aj@arthur.rhein-neckar.de>, libc-hacker@cygnus.com
> This tests exactly for what we are looking for, namely, that inlining
> is available.
That is not in fact the defining characteristic, at least to be
pedantically correct. For standardized functions, if the compiler does not
support `extern inline' or something like it (i.e. a form of inline that
allows later extern redeclarations without complaint), we should omit the
inlines altogether. If they are `static inline' (for a compiler that
supports inline but not `extern inline'), then later valid user
redeclarations using extern will produce warnings or errors. If they are
`inline' (no static), that generates global function definitions in every
file that includes the header, which is not only wasteful but likely to
produce multiple definition errors.