[Top][All Lists]
[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
- older Linux wchar.h vs. gcc 4.3.x,
Eric Blake <=