11:29 a.m.
See <http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes>
Changes:
[eblake] maint: update to latest gnulib
------------------------------------------
[...truncated 5806 lines...]
GEN wchar.h
GEN wctype.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
GEN charset.alias
GEN ref-add.sed
GEN ref-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'>
GEN libvirt.syms
GEN libvirt.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 libvirt_conf_la-netdev_bandwidth_conf.lo
CC libvirt_conf_la-netdev_vport_profile_conf.lo
CC libvirt_conf_la-netdev_vlan_conf.lo
CC libvirt_conf_la-capabilities.lo
CC libvirt_conf_la-domain_conf.lo
CC libvirt_conf_la-domain_audit.lo
CC libvirt_conf_la-domain_nwfilter.lo
CC libvirt_conf_la-snapshot_conf.lo
CC libvirt_conf_la-domain_event.lo
CC libvirt_conf_la-network_conf.lo
CC libvirt_conf_la-nwfilter_params.lo
CC libvirt_conf_la-nwfilter_ipaddrmap.lo
CC libvirt_conf_la-nwfilter_conf.lo
CC libvirt_conf_la-node_device_conf.lo
CC libvirt_conf_la-storage_conf.lo
CC libvirt_conf_la-storage_encryption_conf.lo
CC libvirt_conf_la-interface_conf.lo
CC libvirt_conf_la-secret_conf.lo
CC libvirt_conf_la-cpu_conf.lo
CC libvirt_conf_la-virconsole.lo
CC libvirt_conf_la-device_conf.lo
CCLD libvirt_conf.la
CC libvirt_cpu_la-cpu.lo
CC libvirt_cpu_la-cpu_generic.lo
CC libvirt_cpu_la-cpu_x86.lo
CC libvirt_cpu_la-cpu_s390.lo
CC libvirt_cpu_la-cpu_arm.lo
CC libvirt_cpu_la-cpu_map.lo
CC libvirt_cpu_la-cpu_powerpc.lo
CCLD libvirt_cpu.la
CC libvirt_vmx_la-vmx.lo
CCLD libvirt_vmx.la
CC libvirt_xenxs_la-xen_sxpr.lo
CC libvirt_xenxs_la-xen_xm.lo
CCLD libvirt_xenxs.la
CC libvirt_driver_la-driver.lo
CC libvirt_driver_la-datatypes.lo
CC libvirt_driver_la-fdstream.lo
CC libvirt_driver_la-nodeinfo.lo
CC libvirt_driver_la-libvirt.lo
CC libvirt_driver_la-lock_manager.lo
CC libvirt_driver_la-lock_driver_nop.lo
CC libvirt_driver_la-domain_lock.lo
CCLD libvirt_driver.la
CC libvirt_driver_test_la-test_driver.lo
CCLD libvirt_driver_test.la
CC libvirt_driver_remote_la-remote_driver.lo
CC libvirt_driver_remote_la-remote_protocol.lo
CC libvirt_driver_remote_la-qemu_protocol.lo
CC libvirt_net_rpc_client_la-virnetclientprogram.lo
CC libvirt_net_rpc_client_la-virnetclientstream.lo
CC libvirt_net_rpc_client_la-virnetclient.lo
CCLD libvirt-net-rpc-client.la
CC libvirt_net_rpc_server_la-virnetserverprogram.lo
CC libvirt_net_rpc_server_la-virnetserverservice.lo
CC libvirt_net_rpc_server_la-virnetserverclient.lo
CC libvirt_net_rpc_server_la-virnetservermdns.lo
CC libvirt_net_rpc_server_la-virnetserver.lo
CCLD libvirt-net-rpc-server.la
CC libvirt_net_rpc_la-virnetmessage.lo
CC libvirt_net_rpc_la-virnetprotocol.lo
CC libvirt_net_rpc_la-virnetsocket.lo
CC libvirt_net_rpc_la-virnettlscontext.lo
CC libvirt_net_rpc_la-virkeepaliveprotocol.lo
CC libvirt_net_rpc_la-virkeepalive.lo
CC libvirt_net_rpc_la-virnetsaslcontext.lo
CCLD libvirt-net-rpc.la
CCLD libvirt_driver_remote.la
CC libvirt_driver_openvz_la-openvz_conf.lo
CC libvirt_driver_openvz_la-openvz_driver.lo
CC libvirt_driver_openvz_la-openvz_util.lo
CCLD libvirt_driver_openvz.la
CC libvirt_driver_vmware_la-vmware_driver.lo
CC libvirt_driver_vmware_la-vmware_conf.lo
CCLD libvirt_driver_vmware.la
CC libvirt_driver_vbox_la-vbox_glue.lo
CC libvirt_driver_vbox_la-vbox_driver.lo
CC libvirt_driver_vbox_la-vbox_V2_2.lo
CC libvirt_driver_vbox_la-vbox_V3_0.lo
CC libvirt_driver_vbox_la-vbox_V3_1.lo
CC libvirt_driver_vbox_la-vbox_V3_2.lo
CC libvirt_driver_vbox_la-vbox_V4_0.lo
CC libvirt_driver_vbox_la-vbox_V4_1.lo
CCLD libvirt_driver_vbox.la
CC libvirt_security_manager_la-security_driver.lo
CC libvirt_security_manager_la-security_nop.lo
CC libvirt_security_manager_la-security_stack.lo
CC libvirt_security_manager_la-security_dac.lo
CC libvirt_security_manager_la-security_manager.lo
CC libvirt_security_manager_la-security_selinux.lo
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...:
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/lib/stdio.h>:903:
first defined here
./.libs/libvirt_util.a(libvirt_util_la-virnetlink.o): In function `rpl_fwrite':
<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio...:
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/lib/stdio.h>:903:
first defined here
../gnulib/lib/.libs/libgnu.a(stdio.o): In function `rpl_fwrite':
<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/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/lib/stdio.h>:903:
first defined here
collect2: error: ld returned 1 exit status
make[3]: *** [libvirt.la] Error 1
make[3]: Leaving directory
`<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'>
make[2]: *** [all] Error 2
make[2]: Leaving directory
`<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'>
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/'>
make: *** [all] Error 2
Build step 'Execute shell' marked build as failure
12:20 p.m.
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...:
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
2:14 p.m.
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...:
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
00000760 T rpl_fwrite
00000000 T rpl_fwrite
00000300 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
4:03 p.m.
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
5:50 p.m.
[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
11:04 a.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
The libvirt folks reported[1] a link error of multiple rpl_fwrite
definitions that hits only when optimization and FORTIFY_SOURCE
are both enabled, due to improper use of inline. But since that
particular use of rpl_fwrite exists only to work around a spurious
gcc warning on some versions of glibc, we can use gcc extensions
to acheive the same effect without using inline. This approach
copies the method used in ignore-value.h.
[1] https://lists.gnu.org/archive/html/bug-gnulib/2013-01/msg00014.html
* lib/stdio.in.h (fwrite): Limit warn_unused_result workaround to
just gcc, and in a way that avoids inline issues.
* modules/stdio (Depends-on): Drop extern-inline.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
ChangeLog | 7 +++++++
lib/stdio.in.h | 23 +++++------------------
modules/stdio | 1 -
3 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 73c186d..0bae990 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-01-03 Eric Blake <eblake(a)redhat.com>
+
+ fwrite: silence __wur without using inline
+ * lib/stdio.in.h (fwrite): Limit warn_unused_result workaround to
+ just gcc, and in a way that avoids inline issues.
+ * modules/stdio (Depends-on): Drop extern-inline.
+
2013-01-03 Jim Meyering <jim(a)meyering.net>
update-copyright: avoid copyright notice date corruption
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
index ec39c7d..0f20171 100644
--- a/lib/stdio.in.h
+++ b/lib/stdio.in.h
@@ -46,11 +46,6 @@
#ifndef _@GUARD_PREFIX@_STDIO_H
#define _@GUARD_PREFIX@_STDIO_H
-_GL_INLINE_HEADER_BEGIN
-#ifndef _GL_STDIO_INLINE
-# define _GL_STDIO_INLINE _GL_INLINE
-#endif
-
/* Get va_list. Needed on many systems, including glibc 2.8. */
#include <stdarg.h>
@@ -583,18 +578,12 @@ _GL_CXXALIAS_SYS (fwrite, size_t,
/* 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;
-}
+ This affects only function declaration attributes under certain
+ versions of gcc, and is not needed for C++. */
+# if !defined __cplusplus && 0 < __USE_FORTIFY_LEVEL \
+ && 3 < (__GNUC__ + (4 <= __GNUC_MINOR__))
# undef fwrite
-# define fwrite rpl_fwrite
+# define fwrite(a, b, c, d) ({size_t __r = fwrite (a, b, c, d); __r; })
# endif
# endif
_GL_CXXALIASWARN (fwrite);
@@ -1338,8 +1327,6 @@ _GL_WARN_ON_USE (vsprintf, "vsprintf is not always POSIX
compliant - "
"POSIX compliance");
#endif
-_GL_INLINE_HEADER_END
-
#endif /* _@GUARD_PREFIX@_STDIO_H */
#endif /* _@GUARD_PREFIX@_STDIO_H */
#endif
diff --git a/modules/stdio b/modules/stdio
index c33ad31..54189dc 100644
--- a/modules/stdio
+++ b/modules/stdio
@@ -7,7 +7,6 @@ lib/stdio.in.h
m4/stdio_h.m4
Depends-on:
-extern-inline
include_next
snippet/arg-nonnull
snippet/c++defs
--
1.8.0.2
12:16 p.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
Thanks for fixing that. I'm still puzzled about
why the problem happened with libvirt. It's better now that
stdio doesn't depend on extern-inline, but I worry that whatever
bug the libvirt folks were having with stdio and extern inline
might crop up when extern inline is used in other include files.
One minor improvement is that we can limit the workaround to
glibc versions that have the problem, so I pushed this further
change.
---
ChangeLog | 6 ++++++
lib/stdio.in.h | 8 +++++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0bae990..714ee4c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2013-01-03 Paul Eggert <eggert(a)cs.ucla.edu>
+
+ fwrite: silence __wur only for older glibc versions
+ * lib/stdio.in.h (fwrite): Limit workaround to glibc 2.4 through 2.15.
+ This will help us remove this workaround some time in the far future.
+
2013-01-03 Eric Blake <eblake(a)redhat.com>
fwrite: silence __wur without using inline
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
index f9765d1..c345499 100644
--- a/lib/stdio.in.h
+++ b/lib/stdio.in.h
@@ -575,13 +575,15 @@ _GL_CXXALIAS_RPL (fwrite, size_t,
_GL_CXXALIAS_SYS (fwrite, size_t,
(const void *ptr, size_t s, size_t n, FILE *stream));
-/* Work around glibc bug 11959
+/* Work around bug 11959 when fortifying glibc 2.4 through 2.15
<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 under certain
versions of gcc, and is not needed for C++. */
-# if !defined __cplusplus && 0 < __USE_FORTIFY_LEVEL \
- && 3 < (__GNUC__ + (4 <= __GNUC_MINOR__))
+# if (0 < __USE_FORTIFY_LEVEL \
+ && __GLIBC__ == 2 && 4 <= __GLIBC_MINOR__ &&
__GLIBC_MINOR__ <= 15 \
+ && 3 < __GNUC__ + (4 <= __GNUC_MINOR__) \
+ && !defined __cplusplus)
# undef fwrite
# define fwrite(a, b, c, d) ({size_t __r = fwrite (a, b, c, d); __r; })
# endif
--
1.7.11.7
2:23 p.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
On 01/03/2013 11:16 AM, Paul Eggert wrote:
Thanks for fixing that. I'm still puzzled about
why the problem happened with libvirt.
Why libvirt, and not detected elsewhere? Probably because libvirt does
this at configure time:
AH_VERBATIM([FORTIFY_SOURCE],
[/* Enable compile-time and run-time bounds-checking, and some warnings,
without upsetting newer glibc. */
#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
# define _FORTIFY_SOURCE 2
#endif
and the inline in question is only turned on when _FORTIFY_SOURCE is
enabled. Packages where no one uses _FORTIFY_SOURCE by default would
never hit the issue.
It's better now that
stdio doesn't depend on extern-inline, but I worry that whatever
bug the libvirt folks were having with stdio and extern inline
might crop up when extern inline is used in other include files.
The elided code was not using _GL_EXTERN_INLINE, but _GL_INLINE. They
have different semantics, but I'm hard-pressed to say _which_ semantics
are right from just those names. If I understand correctly, we _want_
the semantics where the inline function is _always_ inlined and never
emitted as a linkable entry point, but I'd have to refer back to C99 and
the gcc manual to see which use of inline and possible __attribute__
combinations guarantees that point. I've seen code that uses the name
ELIDABLE_INLINE for the specific combination we want used in header
files; maybe it's worth adding a name _GL_ELIDABLE_INLINE into
m4/extern-inline.m4 to make it easier to use the results.
One minor improvement is that we can limit the workaround to
glibc versions that have the problem, so I pushed this further
change.
Thanks for that improvement.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:48 p.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
On 01/03/13 12:23, Eric Blake wrote:
The elided code was not using _GL_EXTERN_INLINE, but _GL_INLINE.
They
have different semantics, but I'm hard-pressed to say _which_ semantics
are right from just those names.
Standard C semantics. _GL_EXTERN_INLINE is C99/C11 extern inline.
_GL_INILNE is C99/C11 inline.
If I understand correctly, we _want_
the semantics where the inline function is _always_ inlined and never
emitted as a linkable entry point, but I'd have to refer back to C99 and
the gcc manual to see which use of inline and possible __attribute__
combinations guarantees that point.
Can't be done in Standard C, as far as I know.
With GNU C it can be done with __attribute__((__always_inline__)).
Why is it important that it not be a linkable entry point?
maybe it's worth adding a name _GL_ELIDABLE_INLINE into
m4/extern-inline.m4 to make it easier to use the results.
Sorry, I guess I don't see how this would work.
That is, I can see how _GL_ELIDABLE_INLINE would expand to
'inline __attribute__((__always_inline__))'
in GNU C, but what would it expand to in Standard C?
It can't be expanded to nothing, since you don't want
a linkable entry point, and it can't be expanded to 'static',
at least not in a header, because the resulting function
couldn't be called from an extern inline function.
3 p.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
On 01/03/2013 01:48 PM, Paul Eggert wrote:
Can't be done in Standard C, as far as I know.
Oh well, not worth it then.
With GNU C it can be done with __attribute__((__always_inline__)).
Why is it important that it not be a linkable entry point?
At least in the case libvirt was hitting, multiple files used fwrite,
which in turn meant multiple linkable entries for rpl_fwrite were
emitted when linking things together; but because they weren't marked
'static', the linker didn't like us. If we are going to have a wrapper
inline function in a header, then we want to ensure that the wrapper
does not cause duplicate links.
> maybe it's worth adding a name _GL_ELIDABLE_INLINE into
> m4/extern-inline.m4 to make it easier to use the results.
Sorry, I guess I don't see how this would work.
That is, I can see how _GL_ELIDABLE_INLINE would expand to
'inline __attribute__((__always_inline__))'
in GNU C, but what would it expand to in Standard C?
It can't be expanded to nothing, since you don't want
a linkable entry point, and it can't be expanded to 'static',
at least not in a header, because the resulting function
couldn't be called from an extern inline function.
Indeed, that's an annoying limitation. Which goes to show that what we
did for fwrite (avoid inline altogether, and instead use GNU C instead
of Standard C, to get the workaround we wanted) is really all the best
we can do - we have to use a case-by-case analysis of WHY a wrapper is
in the header, and either pull the wrapper out of a header and into a
real function, or rely on compiler extensions for the cases where the
wrapper only makes sense for that compiler.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:04 p.m.
New subject: [libvirt] [PATCH] fwrite: silence __wur without using inline
On 01/03/2013 01:00 PM, Eric Blake wrote:
in the case libvirt was hitting, multiple files used fwrite,
which in turn meant multiple linkable entries for rpl_fwrite were
emitted when linking things together; but because they weren't marked
'static', the linker didn't like us.
OK, but surely this problem would happen with any extern symbol
that gnulib defines. I.e., it's not a problem specific to
extern inline functions; it's a problem with externs in general.
Isn't the "right" way to handle this, from the gnulib point of view,
the lib-symbol-visibility module? Shouldn't libvirt be using that?
If libvirt was compiled with -fvisibility=hidden then any miscellanous
extern functions that it defined would be local to the libvirt .so,
and wouldn't clash with similarly-named functions in other shared objects.
what we
did for fwrite (avoid inline altogether, and instead use GNU C instead
of Standard C, to get the workaround we wanted) is really all the best
we can do
I hope that's not the case, because it pretty much means
that there's no portable way to use inline functions in
gnulib headers that contribute to shared objects.
11:15 a.m.
New subject: [libvirt] [PATCH] build: fix build with optimization enabled
Build failure detected by Jenkins autobuilder:
http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes
* .gnulib: Update to latest, for stdio.h rpl_fwrite fix.
---
Pushing under the build-breaker rule. I managed to reproduce
the link failure on a RHEL 6 box with CFLAGS='-g -O2', and
also that this gnulib update made it go away.
* .gnulib 964bbc2...61c7b1e (2):
fwrite: silence __wur without using inline
update-copyright: avoid copyright notice date corruption
.gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gnulib b/.gnulib
index 964bbc2..61c7b1e 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 964bbc2d419584e93fe629ddbc40595612f62083
+Subproject commit 61c7b1e32e11e9e40b4d59ab888a807620befcd3
--
1.8.0.2
1 p.m.
New subject: [libvirt] [PATCH] build: fix build with optimization enabled
On Thu, Jan 03, 2013 at 10:15:06AM -0700, Eric Blake wrote:
Build failure detected by Jenkins autobuilder:
http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes
* .gnulib: Update to latest, for stdio.h rpl_fwrite fix.
That fixed it. Thanks a lot! As of the latest update I'm seeing spurious
SIGSEGV on make invocations. I'll diagnose these first until I turn the
list mails back on.
Cheers,
-- Guido
---
Pushing under the build-breaker rule. I managed to reproduce
the link failure on a RHEL 6 box with CFLAGS='-g -O2', and
also that this gnulib update made it go away.
* .gnulib 964bbc2...61c7b1e (2):
> fwrite: silence __wur without using inline
> update-copyright: avoid copyright notice date corruption
.gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gnulib b/.gnulib
index 964bbc2..61c7b1e 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 964bbc2d419584e93fe629ddbc40595612f62083
+Subproject commit 61c7b1e32e11e9e40b4d59ab888a807620befcd3
--
1.8.0.2
4341
days inactive
4343
days old
12 comments
4 participants
participants (4)
-
Eric Blake -
Guido Günther -
Jenkins CI -
Paul Eggert