bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

older Linux wchar.h vs. gcc 4.3.x


From: Eric Blake
Subject: older Linux wchar.h vs. gcc 4.3.x
Date: Tue, 7 Aug 2007 23:22:50 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]