Re: [libvirt] Build failed in Jenkins: libvirt-build #472

[Eric Blake]

[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