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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list