On Fri, Oct 06, 2017 at 07:59:13PM +0200, Bruno Haible wrote:
> Daniel P. Berrange wrote:
> > From my own F28 rawhide install with glibc-2.26.90-16.fc28.x86_64
> >
> > >
> > > 1) The output of
> > > $ nm test-getopt-posix | grep getopt
>
On Thu, Sep 28, 2017 at 04:41:37PM -0700, Paul Eggert wrote:
> 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
override rules e.g. LC_CTYPE=C.UTF-8
will have no effect if LC_ALL is already set.
To deal with this maint.mk should instead set LANG=C, and then
explicitly unset all the other LC_* variables.
Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---
top/maint.mk | 24 +
On Fri, Jun 02, 2017 at 11:18:04AM -0700, Paul Eggert wrote:
> On 06/02/2017 09:25 AM, Daniel P. Berrange wrote:
> > Fedora rawhide is now shipping with glibc 2.25.90 and when trying to
> > build libvirt with gnulib's getopt module, it crashes & burns
> >
> >
Fedora rawhide is now shipping with glibc 2.25.90 and when trying to
build libvirt with gnulib's getopt module, it crashes & burns
CC getopt.lo
In file included from ./getopt.h:57:0,
from ../../../gnulib/lib/getopt.c:26:
../../config.h:2934:25: warning: 'struct
On Thu, May 11, 2017 at 06:03:09PM -0700, Paul Eggert wrote:
> I'm really the wrong person to be fixing this sort of thing since I don't
> use MS-Windows. However, I installed a getopt workaround that I hope is
> obvious, here:
>
>
I'm trying to build libvirt with the latest GNULIB git master, on Mingw64
platform (Fedora 25 based).
I get compile warnings:
getopt.c: In function 'process_long_option':
getopt.c:281:5: warning: implicit declaration of function 'flockfile'
[-Wimplicit-function-declaration]
flockfile
On Thu, May 11, 2017 at 04:36:46PM +0200, Bruno Haible wrote:
> Daniel P. Berrange wrote:
> > Perhaps I'm mis-understanding, but I was looking at this code:
> >
> > h = (HANDLE) _get_osfhandle (pfd[i].fd);
> > assure (h != NULL);
>
On Thu, May 11, 2017 at 03:15:46PM +0200, Bruno Haible wrote:
> Hi Daniel,
>
> > it does not actually make poll() function correctly. We're still passing
> > HANDLE objects to the rpl_select() method, instead of calling
> > the native select() method.
>
> I don't agree with your reasoning. The
On Thu, May 11, 2017 at 01:02:14PM +0100, Daniel P. Berrange wrote:
> The previous commit:
>
> commit 17f1e64f00011fb745019119e21b26e4aba65e4b
> Author: Paul Eggert <egg...@cs.ucla.edu>
> Date: Tue Feb 24 16:16:19 2015 -0800
>
> poll: port to
hich would reintroduce
the compile error reporting, we simply undefine the wrappers
so the code calls the WINSOCK native functions once again.
Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
---
lib/poll.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/poll.c b/lib/poll
On Wed, Apr 19, 2017 at 06:23:33PM +0200, Paolo Bonzini wrote:
>
>
> On 19/04/2017 17:50, Daniel P. Berrange wrote:
> >> But perhaps it's simpler to add "#undef recv" and "#undef select" near
> >> the top of the file, in addition to this change.
&g
On Wed, Apr 19, 2017 at 05:36:54PM +0200, Paolo Bonzini wrote:
>
>
> On 18/04/2017 17:07, Daniel P. Berrange wrote:
> > We're seeing a failure in libvirt on Win32 platforms whereby poll() often
> > returns POLLERR. I traced this down to the rpl_recv() function cal
We're seeing a failure in libvirt on Win32 platforms whereby poll() often
returns POLLERR. I traced this down to the rpl_recv() function calling
FD_TO_SOCKET() and getting INVALID_SOCKET back. This is propagated back
to windows_compute_revents_socket() which sets POLLERR, because
WSAGetLastError()
On Wed, Nov 02, 2016 at 12:47:03PM +0100, Michael Felt wrote:
> On 01/11/2016 13:09, Daniel P. Berrange wrote:
> > On Tue, Nov 01, 2016 at 11:55:12AM -, aixto...@gmail.com wrote:
> > > Granted - the web page is from 7 years ago (now that I look more closely).
> >
On Thu, Aug 13, 2015 at 09:39:48PM +0100, Peter Maydell wrote:
On 13 August 2015 at 19:27, Eric Blake ebl...@redhat.com wrote:
It's worth asking the gnulib folks for an opinion on whether relaxing
the license on maint.mk and GNUmakefile to explicitly go back to GPLv2+,
and/or explicitly add
On Mon, Jan 05, 2015 at 04:06:15PM -0700, Eric Blake wrote:
On 12/15/2014 10:55 AM, Daniel P. Berrange wrote:
On Mon, Dec 15, 2014 at 05:44:22PM +, Daniel P. Berrange wrote:
A previous commit attempted to workaround pollution in the
Mingw64 pthreads.h header file
commit
A previous commit attempted to workaround pollution in the
Mingw64 pthreads.h header file
commit d5fec6c22f03c6a73d62260c9ce091c10c0a9cbd
Author: Eric Blake ebl...@redhat.com
Date: Wed Jan 22 20:39:45 2014 -0700
pthread: work around winpthread header pollution on mingw
It activated
On Mon, Dec 15, 2014 at 05:44:22PM +, Daniel P. Berrange wrote:
A previous commit attempted to workaround pollution in the
Mingw64 pthreads.h header file
commit d5fec6c22f03c6a73d62260c9ce091c10c0a9cbd
Author: Eric Blake ebl...@redhat.com
Date: Wed Jan 22 20:39:45 2014 -0700
On Wed, Apr 23, 2014 at 08:38:07PM -0600, Eric Blake wrote:
On 04/23/2014 04:26 AM, Daniel P. Berrange wrote:
The gnulib usleep replacement says
/* This file is _intentionally_ light-weight. Rather than using
select or nanosleep, both of which drag in external libraries
The gnulib usleep replacement says
/* This file is _intentionally_ light-weight. Rather than using
select or nanosleep, both of which drag in external libraries on
some platforms, this merely rounds up to the nearest second if
usleep() does not exist. If sub-second resolution
I'm attempting to make libvirt capable of building with mingw64 toolchain's
pthread.h, instead of directly using Windows thread primitives.
As a quick hack I just changed libvirt logic to force use of pthreads,
since configure is already doing the neccessary pthread.h probes for us
even on win32
On Wed, Jan 22, 2014 at 04:27:43PM +, Daniel P. Berrange wrote:
I'm attempting to make libvirt capable of building with mingw64 toolchain's
pthread.h, instead of directly using Windows thread primitives.
Sorry, I should have mentioned the versions, Fedora 20, with mingw64 3.0.0
mingw32
On Thu, Aug 02, 2012 at 01:18:12PM +0200, Wido den Hollander wrote:
On 07/08/2012 07:51 PM, Bruno Haible wrote:
Daniel P. Berrange wrote:
If its better to just do it in libvirt config.h, then we
can do that too
Yes, doing '#define foo libvirt_foo' in config.h is the preferred way
On Thu, Aug 02, 2012 at 03:14:27PM +0200, Wido den Hollander wrote:
On 08/02/2012 01:37 PM, Daniel P. Berrange wrote:
On Thu, Aug 02, 2012 at 01:18:12PM +0200, Wido den Hollander wrote:
On 07/08/2012 07:51 PM, Bruno Haible wrote:
Daniel P. Berrange wrote:
If its better to just do
On Wed, Jul 04, 2012 at 04:17:39PM +0200, Wido den Hollander wrote:
On 04-07-12 14:08, Eric Blake wrote:
[adding gnulib]
On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
==6825==
==6825== Invalid read of size 4
==6825==at 0xA57E4B9: base64_encode (in
/usr/lib/x86_64-linux-gnu
On Wed, Jul 04, 2012 at 06:08:59AM -0600, Eric Blake wrote:
[adding gnulib]
On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
==6825==
==6825== Invalid read of size 4
==6825==at 0xA57E4B9: base64_encode (in
/usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
==6825
On Thu, Jun 21, 2012 at 12:42:17PM +0200, Bruno Haible wrote:
Daniel P. Berrange wrote:
Here's what i see in config.status for my libvirt build:
$ grep -i vscanf config.status
S[GNULIB_VSCANF]=0
$ grep STDIO config.status
S[NEXT_AS_FIRST_DIRECTIVE_STDIO_H]=stdio.h
S[NEXT_STDIO_H
On Wed, Jun 20, 2012 at 02:11:32AM +0200, Bruno Haible wrote:
Daniel P. Berrange wrote:
CC stdio-read.lo
../../../gnulib/lib/stdio-read.c:102:1: error: redefinition of 'vscanf'
In file included from ./stdio.h:43:0,
from ../../../gnulib/lib/stdio-read.c:21
On Sun, Jun 17, 2012 at 04:28:02PM +0200, Bruno Haible wrote:
Hello Daniel,
CC fstat.lo
../../../gnulib/lib/fstat.c:27:0: warning: stat redefined [enabled by
default]
In file included from ./sys/stat.h:32:0,
from ../../../gnulib/lib/fstat.c:25:
With current Libvirt master + GNULIB (77cef20) I can successfully
compile using the Mingw32 toolchain. If attempting to use the
alternative Mingw64 toolchain, however, I get a number of errors.
On both x86_64-w64-mingw32 and i686-w64-mingw32 I see the
following:
CC fstat.lo
On Wed, Apr 25, 2012 at 03:04:05PM +0200, Jim Meyering wrote:
Eric Blake wrote:
[adding bug-gnulib]
On 04/24/2012 06:22 AM, Eric Blake wrote:
On 04/24/2012 03:50 AM, Peter Krempa wrote:
Commit c9cd419caba9effa11ca53e8696e5f6a4b424d60 added copying of the
makefile for translation files
On Thu, Mar 29, 2012 at 06:45:03AM -0600, Eric Blake wrote:
On 03/29/2012 03:53 AM, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
Some of the test suites use fprintf with format specifiers
that are not supported on Win32 and are not fixed by gnulib
I noticed that many (most) of the libvirt syntax-check rules were not
generating any results, despite me introducing obvious violations.
From my debugging the problem appears to be caused by this commit:
commit 727075d03c670affa68f71313979781f5ba9bbfc
Author: Eric Blake ebl...@redhat.com
On a Fedora 16 host, with GCC 4.6.1 cross compiled for Mingw32:
gcc version 4.6.1 20110627 (Fedora MinGW 4.6.1-3.fc16) (GCC)
And GNULIB synced to
commit 557f8d27ac9cfd41bf944eb883a1e8a10812603a
Author: Bruno Haible br...@clisp.org
Date: Tue Jan 10 22:28:30 2012 +0100
regex:
On Tue, Oct 25, 2011 at 09:32:13AM -0600, Eric Blake wrote:
[adding bug-gnulib]
On 10/25/2011 03:44 AM, Jiri Denemark wrote:
On Mon, Oct 24, 2011 at 16:44:49 -0600, Eric Blake wrote:
Commit 1726a73 hacked around MacOS' lack of fdatasync, since
gnulib did not have it at the time. But now
On Tue, Oct 25, 2011 at 05:12:57PM +0100, Pádraig Brady wrote:
On 10/25/2011 04:50 PM, Daniel P. Berrange wrote:
On Tue, Oct 25, 2011 at 09:32:13AM -0600, Eric Blake wrote:
[adding bug-gnulib]
On 10/25/2011 03:44 AM, Jiri Denemark wrote:
On Mon, Oct 24, 2011 at 16:44:49 -0600, Eric
On Thu, Jun 30, 2011 at 11:56:15AM -0600, Eric Blake wrote:
[adding libvirt]
On 06/04/2011 12:24 AM, Paolo Bonzini wrote:
On Sat, Jun 4, 2011 at 00:37, Matthias Bolte
matthias.bo...@googlemail.com wrote:
After testing a while and reading MSDN docs the problem seems to be
that
On Tue, Jul 19, 2011 at 09:31:59AM -0600, Eric Blake wrote:
On 07/19/2011 09:30 AM, Daniel P. Berrange wrote:
I'm wondering if the problem here is that libvirt is trying to use the
pipe-to-self mechanism as a fundamental event loop idiom. That is, the
reason libvirt is calling poll
On Wed, May 18, 2011 at 11:27:28AM -0600, Eric Blake wrote:
[adding bug-gnulib]
On 05/18/2011 11:07 AM, Daniel P. Berrange wrote:
strerror_r() is free to not set any error string, if the passed
errno is not valid. It may, however, still return a pointer to
the original passed in buffer
On Thu, Nov 11, 2010 at 01:26:37PM +0100, Bruno Haible wrote:
Here's a draft proposal: A new module 'strerror_r-posix'. I wouldn't want
to call it 'strerror_r' because that would be misunderstandable.
During testing, more portability problems appeared. Here's what I'm
committing:
#else
On Mon, Nov 08, 2010 at 12:07:57PM -0700, Eric Blake wrote:
On 11/07/2010 01:35 AM, Justin Clift wrote:
Hi Eric,
When running 'make check' on OSX (git head) it's erroring out with:
eventtest.c: In function 'finishJob':
eventtest.c:216: warning: implicit declaration of function
On Wed, Aug 18, 2010 at 09:54:51AM -0600, Eric Blake wrote:
On 08/18/2010 08:30 AM, Eric Blake wrote:
Still, I'm reluctant to bite the bullet and go with the LGPLv2+ cascade
on vasprintf-posix. So maybe the solution is an intermediate module:
LGPLv2+ vasprintf - bare bones, guarantees a
I've been using the GNULIB poll() impl in libvirt on Win32 (well Mingw +
WINE) and found it was producing really wierd results, such ret=-1 +
errno=EAGAIN, or ret=0 even though requested timeout was infinite.
After a little debugging I discovered a missing initialization of
the 'rc' variable in
44 matches
Mail list logo
