C99 inline semantics

[rdb]

Some projects quite reasonably assume that C99 inline semantics are used when compiling in -std=c99 or -std=c11 modes, which are well supported by GCC 4.8.

However, the default for the compiler seems to be -fgnu89-inline, which forces incompatible pre-C99 inline semantics even in C99/C11 mode, which can cause quite some confusing "multiple definition" errors in libraries that rely on the correct semantics.

Unfortunately, adding -fno-gnu89-inline isn't quite enough to fix this, because the libc headers in /usr/include are apparently not compatible with C99 semantics. More recent versions of the headers explicitly force gnu89 inline semantics for these headers by using the __gnu_inline__ compiler attribute, which was introduced around the time that C99 support was.

So, besides adding -fno-gnu89-inline to my CFLAGS, I have to add this monkey patch to my dockerfile to make libraries like OpenAL compile:
find /usr/include/ -type f -exec sed -i 's/\bextern _*inline_*\b/extern __inline __attribute__ ((__gnu_inline__))/g' {} +

Assuming we no longer need to support GCC 4.2, perhaps we could add this command to the manylinux dockerfile? It would still only be half of the solution, since I believe it is still rather odd for GCC to apply gnu89 inline semantics in C99/C11 modes, but the latter is much easier to work around by adding said flag to CFLAGS.

Alternatively, would it be possible to update the libc headers without breaking compatibility?

[njsmith]

Well, that sounds ugly all around. I guess patching the include files like you suggest wouldn't hurt anything, so why not? Are there any downsides? (It sounds like you might be saying that it would break GCC 4.2 compatibility? I can't quite tell.)

Alternatively I guess it wouldn't be the end of the world to push this off to be part of your build scripts, and RHEL5 goes EOL at the end of March 2017, so probably we'll all be switching to CentOS 6 + GCC 5.2 soon-ish and that should take care of this issue. (Making the transition will require someone write up a "manylinux2" spec and such -- not too hard, but someone has to volunteer to do it, so the exact timeline is not clear.)

[rdb]

I can't really think of a downside. GCC 4.2 and below would produce a warning akin to "__gnu_inline__" attribute directive ignored or some such thing. Maybe some esoteric compiler would complain about the attribute. We could certainly make the hack more elaborate to avoid this but I got the impression that we want people to use the bundled GCC 4.8.

I'm fine keeping the hack in my local dockerfile but I figured that other people are likely to run into this as well.

[njsmith]

I can't really think of a downside.

Okay, why not :-). Want to submit a PR?