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 t
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 o
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:
>
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
>
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
> > wrote:
> >> After testing a while and reading MSDN docs the problem seems to be
> >> that MsgWaitForMultipleObjects
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
> >
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, guar
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.
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:
&g
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
Date: Tue Jan 10 22:28:30 2012 +0100
regex: Avoid link error on
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"
> >
> > Some of the test suites use fprintf with format specifiers
> > that are not supported on Win32 and are not
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
Date: Thu Mar 1
On Thu, Apr 05, 2012 at 06:07:20AM -0600, Eric Blake wrote:
> On 04/05/2012 04:10 AM, Bruno Haible wrote:
> You forgot to check one (64-bit mingw64):
>
> $ x86_64-w64-mingw32-gcc -E foo.c | grep size_t
> __extension__ typedef unsigned long long size_t;
> __extension__ typedef long long ssize_t;
>
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
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
../../../gnulib/
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:
> >
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,
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"
> >
> > $
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 r
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
&g
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 f
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 wrot
e compile error reporting, we simply undefine the wrappers
so the code calls the WINSOCK native functions once again.
Signed-off-by: Daniel P. Berrange
---
lib/poll.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/poll.c b/lib/poll.c
index c4b2127..a26838c 100644
--- a/lib/pol
On Thu, May 11, 2017 at 01:02:14PM +0100, Daniel P. Berrange wrote:
> The previous commit:
>
> commit 17f1e64f00011fb745019119e21b26e4aba65e4b
> Author: Paul Eggert
> Date: Tue Feb 24 16:16:19 2015 -0800
>
> poll: port to MSVC v18 on MS-Windows 8.1
>
>
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 se
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);
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 (stder
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:
>
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=19fb4184b09
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 rpl_option'
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
> >
> &g
ively 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
---
top/maint.mk | 24 +---
1 file change
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 it
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
>
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 e
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
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 is
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
A previous commit attempted to workaround pollution in the
Mingw64 pthreads.h header file
commit d5fec6c22f03c6a73d62260c9ce091c10c0a9cbd
Author: Eric Blake
Date: Wed Jan 22 20:39:45 2014 -0700
pthread: work around winpthread header pollution on mingw
It activated its workaround bas
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
> Date: Wed Jan 22 2
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 +0000, Daniel P. Berrange wrote:
> >> A previous commit attempted to workaround pollution in the
> >> Min
On Thu, Aug 13, 2015 at 09:39:48PM +0100, Peter Maydell wrote:
> On 13 August 2015 at 19:27, Eric Blake 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 some expli
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).
> >
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, 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 call
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 chang
45 matches
Mail list logo
