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. -- 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