On 01/03/2013 01:00 PM, Eric Blake wrote:
> in the case libvirt was hitting, multiple files used fwrite,
> which in turn meant multiple linkable entries for rpl_fwrite were
> emitted when linking things together; but because they weren't marked
> 'static', the linker didn't like us.
OK, but surel
On 01/03/2013 01:48 PM, Paul Eggert wrote:
> Can't be done in Standard C, as far as I know.
Oh well, not worth it then.
> With GNU C it can be done with __attribute__((__always_inline__)).
>
> Why is it important that it not be a linkable entry point?
At least in the case libvirt was hitting, m
On 01/03/13 12:23, Eric Blake wrote:
> 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.
Standard C semantics. _GL_EXTERN_INLINE is C99/C11 extern inline.
_GL_INILNE
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
Thanks for fixing that. I'm still puzzled about
why the problem happened with libvirt. 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 fil
The libvirt folks reported[1] a link error of multiple rpl_fwrite
definitions that hits only when optimization and FORTIFY_SOURCE
are both enabled, due to improper use of inline. But since that
particular use of rpl_fwrite exists only to work around a spurious
gcc warning on some versions of glibc
