[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
signature.asc
Description: OpenPGP digital signature
