[libvirt] Build failed in Jenkins: libvirt-build #472
See http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes Changes: [eblake] maint: update to latest gnulib -- [...truncated 5806 lines...] GENwchar.h GENwctype.h make all-am make[3]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib' CC allocator.lo CC areadlink.lo CC base64.lo CC binary-io.lo CC bitrotate.lo CC c-ctype.lo CC c-strcasecmp.lo CC c-strncasecmp.lo CC c-strcasestr.lo CC careadlinkat.lo CC cloexec.lo CC count-one-bits.lo CC md5.lo CC sha256.lo CC dirname-lgpl.lo CC basename-lgpl.lo CC stripslash.lo CC fd-hook.lo CC freading.lo CC localcharset.lo CC lock.lo CC malloca.lo CC nonblocking.lo CC passfd.lo CC physmem.lo CC pipe2.lo CC sig-handler.lo CC sockets.lo CC stat-time.lo CC stdio.lo CC strnlen1.lo CC sys_socket.lo CC tempname.lo CC threadlib.lo CC unistd.lo CC wctype-h.lo CC xsize.lo CC asnprintf.lo CC fclose.lo CC fcntl.lo CC fflush.lo CC fpurge.lo CC fseek.lo CC fseeko.lo CC ioctl.lo CC mktime.lo CC perror.lo CC printf-args.lo CC printf-parse.lo CC strerror.lo CC strerror_r.lo CC vasnprintf.lo CCLD libgnu.la GENcharset.alias GENref-add.sed GENref-del.sed make[3]: Leaving directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib' make[2]: Leaving directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib' Making all in include make[2]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include' Making all in libvirt make[3]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include/libvirt' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include/libvirt' make[3]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include' make[2]: Leaving directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include' Making all in src make[2]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src' GENlibvirt.syms GENlibvirt.def make all-am make[3]: Entering directory `http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src' CC libvirt_util_la-viralloc.lo CC libvirt_util_la-virarch.lo CC libvirt_util_la-viratomic.lo CC libvirt_util_la-viraudit.lo CC libvirt_util_la-virauth.lo CC libvirt_util_la-virauthconfig.lo CC libvirt_util_la-virbitmap.lo CC libvirt_util_la-virbuffer.lo CC libvirt_util_la-vircgroup.lo CC libvirt_util_la-vircommand.lo CC libvirt_util_la-virconf.lo CC libvirt_util_la-virdbus.lo CC libvirt_util_la-virdnsmasq.lo CC libvirt_util_la-virebtables.lo CC libvirt_util_la-virerror.lo CC libvirt_util_la-virevent.lo CC libvirt_util_la-vireventpoll.lo CC libvirt_util_la-virfile.lo CC libvirt_util_la-virhash.lo CC libvirt_util_la-virhashcode.lo CC libvirt_util_la-virhook.lo CC libvirt_util_la-virinitctl.lo CC libvirt_util_la-viriptables.lo CC libvirt_util_la-virjson.lo CC libvirt_util_la-virkeycode.lo CC libvirt_util_la-virkeyfile.lo CC libvirt_util_la-virlockspace.lo CC libvirt_util_la-virlog.lo CC libvirt_util_la-virmacaddr.lo CC libvirt_util_la-virnetdev.lo CC libvirt_util_la-virnetdevbandwidth.lo CC libvirt_util_la-virnetdevbridge.lo CC libvirt_util_la-virnetdevmacvlan.lo CC libvirt_util_la-virnetdevopenvswitch.lo CC libvirt_util_la-virnetdevtap.lo CC libvirt_util_la-virnetdevveth.lo CC libvirt_util_la-virnetdevvlan.lo CC libvirt_util_la-virnetdevvportprofile.lo CC libvirt_util_la-virnetlink.lo CC libvirt_util_la-virnodesuspend.lo CC libvirt_util_la-virobject.lo CC libvirt_util_la-virpci.lo CC libvirt_util_la-virpidfile.lo CC libvirt_util_la-virprocess.lo CC libvirt_util_la-virrandom.lo CC libvirt_util_la-virsexpr.lo CC libvirt_util_la-virsocketaddr.lo CC libvirt_util_la-virstatslinux.lo CC libvirt_util_la-virstoragefile.lo CC libvirt_util_la-virstring.lo CC libvirt_util_la-virsysinfo.lo CC libvirt_util_la-virthread.lo CC libvirt_util_la-virthreadpool.lo CC libvirt_util_la-virtime.lo CC libvirt_util_la-virtypedparam.lo CC libvirt_util_la-virusb.lo CC libvirt_util_la-viruri.lo CC libvirt_util_la-virutil.lo CC libvirt_util_la-viruuid.lo CC libvirt_util_la-virxml.lo CCLD libvirt_util.la CC
Re: [libvirt] Build failed in Jenkins: libvirt-build #472
On 01/02/2013 10:29 AM, Jenkins CI wrote: See http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes Changes: [eblake] maint: update to latest gnulib CCLD libvirt_security_manager.la CCLD libvirt.la ./.libs/libvirt_util.a(libvirt_util_la-virnetdevtap.o): In function `rpl_fwrite': http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h:903: multiple definition of `rpl_fwrite' ./.libs/libvirt_util.a(libvirt_util_la-virnetdev.o):http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lb/stdio.h:903: first defined here Yuck. This sounds like an issue in upstream gnulib inline handling. I see this from your logs: checking build system type... i686-pc-linux-gnu but that doesn't tell me what version of glibc and gcc you are using, in case the problem is an interaction between those (as is, I recently reported[1] a case where a mismatch of old glibc and new gcc causes build failures, but that was on a modified RHEL 5 box, so probably doesn't match your setup). [1] https://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg00176.html I haven't been able to reproduce the failure locally on any of my Fedora or RHEL boxes, using incremental builds; I am also in the middle of trying a fresh clone build, to see if that is any different. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Build failed in Jenkins: libvirt-build #472
Hi, On Wed, Jan 02, 2013 at 11:20:08AM -0700, Eric Blake wrote: On 01/02/2013 10:29 AM, Jenkins CI wrote: See http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes Changes: [eblake] maint: update to latest gnulib CCLD libvirt_security_manager.la CCLD libvirt.la ./.libs/libvirt_util.a(libvirt_util_la-virnetdevtap.o): In function `rpl_fwrite': http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h:903: multiple definition of `rpl_fwrite' ./.libs/libvirt_util.a(libvirt_util_la-virnetdev.o):http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lb/stdio.h:903: first defined here Yuck. This sounds like an issue in upstream gnulib inline handling. I see this from your logs: checking build system type... i686-pc-linux-gnu but that doesn't tell me what version of glibc and gcc you are using, in case the problem is an interaction between those (as is, I recently reported[1] a case where a mismatch of old glibc and new gcc causes build failures, but that was on a modified RHEL 5 box, so probably doesn't match your setup). [1] https://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg00176.html 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 0760 T rpl_fwrite T rpl_fwrite 0300 T rpl_fwrite Any information I can provide to diagnose this further? -- Guido P.S.: I've removed the mailing list from the build reports temporarily to not spam the list with new build failures until this is fixed. I haven't been able to reproduce the failure locally on any of my Fedora or RHEL boxes, using incremental builds; I am also in the middle of trying a fresh clone build, to see if that is any different. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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
0760 T rpl_fwrite
T rpl_fwrite
0300 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
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Build failed in Jenkins: libvirt-build #472
[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
0760 T rpl_fwrite
T rpl_fwrite
0300 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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
