gcc4 issues with extern inlines and -std=gnu99

[titer]

To reproduce, create those two files:

==> 1.c <==
#include <libio.h>
int main()
{
    return 0;
}
==> 2.c <==
#include <libio.h>

And run:

> gcc -std=gnu99 -o foo 1.c 2.c 
/tmp//cce84I9p.o: In function `_IO_getc_unlocked':
2.c:(.text+0x0): multiple definition of `_IO_getc_unlocked'
/tmp//ccblPZxd.o:1.c:(.text+0x0): first defined here
/tmp//cce84I9p.o: In function `_IO_peekc_unlocked':
2.c:(.text+0x59): multiple definition of `_IO_peekc_unlocked'
/tmp//ccblPZxd.o:1.c:(.text+0x59): first defined here
/tmp//cce84I9p.o: In function `_IO_putc_unlocked':
2.c:(.text+0xb2): multiple definition of `_IO_putc_unlocked'
/tmp//ccblPZxd.o:1.c:(.text+0xb2): first defined here
collect2: ld returned 1 exit status

The multiple definitions are caused by "extern __inline" functions in libio.h. I don't really know whether the problem lies in the header or in gcc, but building this with gcc2 (even with -std=gnu9x) works, and it also builds with gcc4 if you remove the -std option.

I noticed that while attempting to build VLC 1.0.0, which force C99 mode, on Haiku/gcc4 hrev29420 with gcc-4.3.3-haiku-090129.

[titer]

Here is an interesting post about extern inline and C99 from the GCC mailing list: ​http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html

Short story is, gcc -std=gnu99 emitting an externally visible symbol for those functions is correct with regard to C99, the headers just aren't C99-friendly.

How about switching all those "extern inline"s to "static inline"s in order to make all GCCs happy?

From what I understand, the only difference is that "extern inline" (in non-C99) lets you override the definition with a local one, but this should not be needed in most, if not all cases. And if we do need it, C99 does not provide that feature so we'd need another way to do that.

[titer]

Mmmh, I didn't search well enough in the already open issues - this is the same bug as #3481.