If you aren't already aware, the (not-yet-released) gcc 4.3 is changing the semantics of 'extern inline' functions to obey C99 semantics when called with std=gnu99. The net result of this change is that functions declared in headers that relied on the old gcc semantics to be inline-only will now cause multiple- definition link errors.
An example of this is reported on this thread from the M4 list: http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2346 where the reporter is an early adopter of the latest gcc snapshot from svn, but who was unaware of the semantics change and had not upgraded his system headers to match (ie. he was a bit foolhardy for trying the bleeding-edge unreleased gcc but not bleeding-edge glibc, all without reading about the consequences). We will probably start seeing reports like this more frequently as gcc 4.3 is adopted, especially since gnulib projects tend to prefer std=gnu99 when a gcc compiler is detected. Can anyone think of a way to detect broken system headers that were relying on 'extern inline', in such a way that we can make the gnulib wrapper headers nuke those troublesome declarations out of the headers? You can't really define away 'extern', nor 'inline', as both terms have distinct semantics that would break when used in isolation; it really is the pair 'extern inline' that causes the problem. Are we stuck with just telling these users that they shouldn't upgrade gcc without also upgrading their headers, because the old headers are broken with the new gcc? -- Eric Blake
