On 01/03/2013 11:16 AM, Paul Eggert wrote:
Thanks for fixing that. I'm still puzzled about why the problem happened with libvirt.
Why libvirt, and not detected elsewhere? Probably because libvirt does this at configure time: AH_VERBATIM([FORTIFY_SOURCE], [/* Enable compile-time and run-time bounds-checking, and some warnings, without upsetting newer glibc. */ #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ # define _FORTIFY_SOURCE 2 #endif and the inline in question is only turned on when _FORTIFY_SOURCE is enabled. Packages where no one uses _FORTIFY_SOURCE by default would never hit the issue.
It's better now that stdio doesn't depend on extern-inline, but I worry that whatever bug the libvirt folks were having with stdio and extern inline might crop up when extern inline is used in other include files.
The elided code was not using _GL_EXTERN_INLINE, but _GL_INLINE. They have different semantics, but I'm hard-pressed to say _which_ semantics are right from just those names. If I understand correctly, we _want_ the semantics where the inline function is _always_ inlined and never emitted as a linkable entry point, but I'd have to refer back to C99 and the gcc manual to see which use of inline and possible __attribute__ combinations guarantees that point. I've seen code that uses the name ELIDABLE_INLINE for the specific combination we want used in header files; maybe it's worth adding a name _GL_ELIDABLE_INLINE into m4/extern-inline.m4 to make it easier to use the results.
One minor improvement is that we can limit the workaround to glibc versions that have the problem, so I pushed this further change.
Thanks for that improvement. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org