[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]