[adding gnulib in cc] On 01/02/2013 03:03 PM, Eric Blake wrote:
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 http://libvirt.org