On 01/02/2013 01:14 PM, Guido Günther wrote:
>
> This is gcc 4.7.1 and eglibc 2.13. I upgraded to Debian Wheezy's current
> gcc 4.7.2 without any changes. I'm not able to reproduce it locally on a
> Debian sid system either. I also tried a clean bootstrap
>
>
http://honk.sigxcpu.org:8001/job/libvirt-build/474/
>
> but the problem persists:
>
> $ nm src/.libs/libvirt_util.a | grep rpl_fwrite
> 00000760 T rpl_fwrite
> 00000000 T rpl_fwrite
> 00000300 T rpl_fwrite
>
> Any information I can provide to diagnose this further?
Sure - can you paste the portion of libvirt/gnulib/lib/stdio.h that
shows why rpl_fwrite was enabled in the first place? The original
template file stdio.in.h looks like:
#if @GNULIB_FWRITE@
# if @REPLACE_STDIO_WRITE_FUNCS@ && (@GNULIB_STDIO_H_NONBLOCKING@ ||
@GNULIB_STDIO_H_SIGPIPE@)
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef fwrite
# define fwrite rpl_fwrite
# endif
_GL_FUNCDECL_RPL (fwrite, size_t,
On my F18 box, I see:
#if 1
# if 0 && (1 || 1)
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef fwrite
# define fwrite rpl_fwrite
# endif
_GL_FUNCDECL_RPL (fwrite, size_t,
which means that there is no replacement of stdio write functions on
glibc; reading the source code of .gnulib/m4/stdio_h.m4,
REPLACE_STDIO_WRITE_FUNCS is only set to 1 if gl_SIGNAL_SIGPIPE detects
an unusual situation. So something in eglibc is tripping up
gl_SIGNAL_SIGPIPE; maybe finding that portion of config.log will help
understand root cause.
Then again, your configure output shows:
checking for SIGPIPE... yes
which says gl_SIGNAL_SIGPIPE didn't find anything unusual.
Oh, maybe the next culprit - I was compiling at -O0, which disables
fortification (since that only works at -O1 or higher); in the gnulib
stdio.h I see:
/* Work around glibc bug 11959
<
http://sources.redhat.com/bugzilla/show_bug.cgi?id=11959>,
which sometimes causes an unwanted diagnostic for fwrite calls.
This affects only function declaration attributes, so it's not
needed for C++. */
# if !defined __cplusplus && 0 < __USE_FORTIFY_LEVEL
_GL_STDIO_INLINE size_t _GL_ARG_NONNULL ((1, 4))
rpl_fwrite (const void *ptr, size_t s, size_t n, FILE *stream)
{
size_t r = fwrite (ptr, s, n, stream);
(void) r;
return r;
}
# undef fwrite
# define fwrite rpl_fwrite
# endif
It could be that while this works for glibc, it causes grief on eglibc,
especially depending on what _GL_STDIO_INLINE expands to at the time.
Aha, I reproduced the problem on glibc while using RHEL 6.3 and default
CFLAGS (instead of my more typical CFLAGS=-g devel override).
Definitely a problem in Paul's recent work on inline magic, where
_GL_STDIO_INLINE is not doing the intended actions. Paul, any thoughts
on what we need to do to fix this? Also, since that glibc bug (of a
bogus __wur attribute on fwrite) has since been fixed, is the
unconditional override to rpl_fwrite something that is still useful to
keep around?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library