[libvirt] [PATCH] fflush: be more paranoid about libio.h change

/fseeko.c | 6 -- lib/fseterr.c| 3 ++- lib/fwritable.c | 3 ++- lib/fwriting.c | 3 ++- 14 files changed, 53 insertions(+), 16 deletions(-) diff --git a/ChangeLog b/ChangeLog index e858e18fb..a9cd4aed1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,24 @@ +2018-03-08 Paul Eggert

Re: [libvirt] fseeko broken by Fedora rawhide glibc / git master (ie future 2.28)

On 03/05/2018 11:20 AM, Daniel P. Berrangé wrote: Yes, this worked on rawhide when I tested with libvirt. Thanks, I installed it into Gnulib since it was breaking builds. Bruno's the expert here, and perhaps he can come up with something better. -- libvir-list mailing list libvir-list@redha

Re: [libvirt] fseeko broken by Fedora rawhide glibc / git master (ie future 2.28)

around the bug from the Gnulib side; does it work for you? (I haven't tried it on rawhide.) From 1831628c0630ae96a43586b2a25ca51cbdba3e53 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Mar 2018 10:56:29 -0800 Subject: [PATCH] fflush: adjust to glibc 2.28 libio.h removal MIME-Versi

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

On 09/29/2017 05:02 AM, Christian Ehrhardt wrote: Here [1] a log of your commands on such a system showing the issue. Thanks, but I still don't understand what the bug is. With those commands, the test programs use Gnulib-supplied getopt, not the glibc getopt. So why would any change in glibc

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

That patch essentially negates the point of the test, which is that getopt should be visible from unistd.h. I'd rather fix the problem than nuke the test. Could you explain what the Gnulib problem is here? I can't really see it in your email. A self-contained example would help. For what it'

Re: [libvirt] [PATCH] util: Fix build on s390

On 10/13/2016 12:14 PM, Eric Blake wrote: I think a configure test based on -Werror=format would be sufficient What we have now should work for GCC 2.0 and later, whereas -Werror=format is a much-newer GCC feature and so would be less portable. if they are using some other compiler, then ch

Re: [libvirt] [PATCH] util: Fix build on s390

u can think of a way to test whether SIZE_MAX has the correct type on pre-C11 compilers that lack __typeof__, please let me know. From df544bd79a83880cc3287d43c5be1719e1ca2ccf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 13 Oct 2016 11:16:40 -0700 Subject: [PATCH] stdint: port SIZE_MAX to

Re: [libvirt] [PATCH] maint: use $(SED) instead of sed for syntax-check

On 01/27/2014 01:03 PM, Eric Blake wrote: I'd like some feedback from the gnulib community if favoring $(SED) is the right thing to do, or if I should just rewrite libvirt's rules to stick to portable sed constructs. My kneejerk reaction is that we'd probably have fewer problems using '$(SED)'

Re: [libvirt] struct random on FreeBSD [was: FreeBSD-8.3 build failure for amd64/i386, build archive included]

On 09/30/13 09:09, Jason Helfman wrote: > > http://redports.org/~jgh/20130930154500-61365-148605/libvirt-1.1.2.log > > > However the build still fails, but looks to be a more standard failure "internal compiler error: Segm

Re: [libvirt] [PATCH 4/6] Correctly detect warning flags with clang

WARN_ADD): Use it. --- ChangeLog | 8 m4/warnings.m4 | 15 --- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 08f2fe0..b7aceaa 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2013-05-15 Paul Eggert + + warnin

Re: [libvirt] [PATCH 1/6] Ensure consistent enablement of gcc 'diagnostic' pragma

On 05/13/13 12:16, Eric Blake wrote: > I wonder if gnulib should use something similar, for the > places where it uses pragma gcc push. I hope not. The only place gnulib does a push, is to turn off bogus diagnostics that I hope clang doesn't generate. If I'm wrong I suppose we can add an "|| __c

Re: [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 surel

Re: [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

Re: [libvirt] [PATCH] fwrite: silence __wur without using inline

g index 0bae990..714ee4c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2013-01-03 Paul Eggert + + 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 s

Re: [libvirt] [PATCH] Pass a correct pointer type to localtime_r(3).

On 09/04/2012 08:20 AM, Eric Blake wrote: > tv_sec is required by POSIX to be > of type time_t; so this is a bug in the OpenBSD header Most likely this problem arose because of the patch I pushed in gnulib commit e07d7c40f3ca5ec410cf5aa6fa03cfe51e712039. Previously, gnulib required timeval's tv_se

Re: [libvirt] regcomp warnings using Mingw64 toolchain

On 06/17/2012 07:00 AM, Bruno Haible wrote: > For portability the cast to 'long' should better be replaced with a cast > to 'intptr_t'. Thanks, I did that, except I used uintptr_t since the value in question is a size_t value. regex: avoid warning when pointers are not long * lib/regcomp.c (parse

Re: [libvirt] boostrap: gzip version check problem on FreeBSD

On 11/12/2010 12:50 PM, Eric Blake wrote: > + s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/ Surely that is a typo. The "*\)\)*" should be a "*\)*\)". -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list