Paolo Bonzini | 1 Jul 08:19 2011
Picon

Re: mingw: test-poll pipe part fails

On 06/30/2011 07:56 PM, Eric Blake wrote:
> >  Yes, Windows pipes are that broken.:(
> >
> >  Using socketpair is a possibly good idea, but I would do it on
> >  libvirtd only.  I don't know exactly how libvirtd uses this pipe, but
> >  perhaps it can be changed to an eventfd-like abstraction that can be
> >  used with both Windows and Unix.  This is similar to Eric's
> >  suggestion, but without the pipe at all.  It would also be a
> >  libvirtd-specific suggestion.
>
> 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 is in order to minimize CPU until
> something interesting happens, where interesting includes needing to
> wake up a helper thread to do an action inside locks in response to the
> receipt of a signal.
>
> Maybe you are on to something, and replacing all uses of pipe() with
> virPipeToSelf() (which uses pipe() for efficiency on Linux, but
> socketpair() on mingw), would allow libvirt to continue to use the
> pipe-to-self idiom while also using fds that can actually be poll'd on
> mingw.

Perhaps gnulib can provide an eventfd abstraction (or better, a slight 
variation that only returns 0/1) to be used for pipe-to-self.  In 
Windows it can use an autoreset event, in Linux an eventfd, in Unix a pipe.

Paolo

(Continue reading)

Eric Blake | 1 Jul 15:06 2011
Picon

Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw

[adding bug-gnulib, bug-gnu-libiconv]

On 07/01/2011 04:50 AM, Matthias Bolte wrote:
> 2011/6/30 Eric Blake <eblake <at> redhat.com>:
>> On 06/30/2011 12:00 PM, Eric Blake wrote:
>>> Gnulib documents that mingw [v]snprintf is broken (it returns -1
>>> on out-of-space, instead of the count of what would have been
>>> printed); but while we were using the snprintf wrapper, we had
>>> not yet been using the vsnprintf wrapper.
>>>
>>> * bootstrap.conf (gnulib_modules): Add vsnprintf.
>>> Reported by Matthias Bolte.
>>> ---
>>>  bootstrap.conf |    1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> Followup.  There are two forks of mingw - the older mingw project is
>> 32-bit only, and has added wrappers into their w32api libraries that
>> substitute the broken [v]snprintf of msvcrt with a mingw-specific one
>> that is POSIX-compliant out of the box.  Then there is the mingw64
>> project, which can compile for both 32-bit and 64-bit, and where their
>> w32api libraries do not yet override [v]snprintf.  [For reference,
>> Fedora 15 uses the older mingw project, but Fedora 16 is hoping to
>> switch to the newer mingw64 project; meanwhile, cygwin ships with
>> cross-compilers for both flavors, which is how I tested the vsnprintf
>> behavior of both flavors]
>>
>> The gnulib documentation tends to lag various mingw fixes, and (to date)
>> has not been making any distinction between the mingw and mingw64 projects.
>>
(Continue reading)

Eric Blake | 1 Jul 15:50 2011
Picon

Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw

On 07/01/2011 07:06 AM, Eric Blake wrote:
> Why is libintl's [v]snprintf broken on mingw?  Even if libintl is
> compiled against an older mingw where there is no mingw snprintf
> replacement, it seems like libintl should be honoring the correct return
> values.

It is because libintl on mingw is specifically using _vsnprintf (the
broken msvcrt version) rather than vsnprintf (the fixed mingw override):
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/printf.c#n195

in order to fix the fact that both Microsoft and mingw's override do not
understand %1$d, but libintl must support argument reordering.

> 
> And what can gnulib do to work around the case where mingw has fixed
> snprintf, but libintl still has broken snprintf, and thus the gnulib
> headers did not define snprintf?  Should the gnulib <stdio.h>
> replacement _always_ define snprintf, even if only by:
> 
> #define snprintf snprintf
> 
> so that inclusion of the gnulib header prior to the libintl headers
> forces libintl to leave well enough alone?

But now we have a problem - if gnulib did _not_ replace snprintf because
it probed the mingw version and found that the return value was correct,
then the libintl override violates gnulib's assumptions.  If gnulib
_does_ replace snprintf, but does not support %1$d, then gnulib violates
libintl's assumptions.  So it sounds like the LGPLv2+ gnulib modules
[v]snprintf need to guarantee %1$d parsing, since libvirt is not in a
(Continue reading)

Eric Blake | 1 Jul 18:13 2011
Picon

Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw

On 07/01/2011 07:50 AM, Eric Blake wrote:
> But now we have a problem - if gnulib did _not_ replace snprintf because
> it probed the mingw version and found that the return value was correct,
> then the libintl override violates gnulib's assumptions.  If gnulib
> _does_ replace snprintf, but does not support %1$d, then gnulib violates
> libintl's assumptions.

One bit of good news - I confirmed (by modifying test-vsnprintf, then
testing on mingw64, where the gnulib replacement _does_ kick in) that
gnulib's vsnprintf replacement supports %1$d out of the box without any
further m4 tests, and without having to drag in the vsnprintf-posix
module.  So at this point, the patch for mingw is as simple as ensuring
that the gnulib snprintf replacement always kicks in.  Proposed patch
coming up soon.

--

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

On 07/01/2011 07:50 AM, Eric Blake wrote:
> But now we have a problem - if gnulib did _not_ replace snprintf because
> it probed the mingw version and found that the return value was correct,
> then the libintl override violates gnulib's assumptions.  If gnulib
> _does_ replace snprintf, but does not support %1$d, then gnulib violates
> libintl's assumptions.

One bit of good news - I confirmed (by modifying test-vsnprintf, then
testing on mingw64, where the gnulib replacement _does_ kick in) that
(Continue reading)

Eric Blake | 1 Jul 18:27 2011
Picon

[PATCH] snprintf: guarantee %1$d, for libintl

Newer mingw (but not yet mingw64) provides two flavors of
snprintf: _snprintf defers straight to msvcrt, which has broken
return value and does not understand %llu or %zu; and snprintf,
which fixes these two bugs but does not understand %1$s.

Libintl specifically favors _snprintf, with broken return value,
even when compiled on mingw with a fixed snprintf, because the
only behavior which it wants to fix is %1$s handling.  But this
means that the replacement libintl_snprintf has a broken return.

If one uses the 'snprintf-posix' module, then the gnulib
replacement kicks in, and does everything that libintl needs, so
on mingw, <libintl.h> specifically avoids overriding snprintf if
it detected that gnulib replaced snprintf.  However, if one only
uses the 'snprintf' module and also uses libintl, this means
there are two problems:

1. The gnulib 'snprintf' module does not replace the mingw
snprintf function, because it has proper return values, while the
libintl.h header knows that %1$d is broken so snprintf must be
replaced, with the end result that the application gets the
libintl replacement snprintf with broken return values in spite
of the gnulib module.

2. Conversely, if the application did '#define snprintf snprintf',
that would be enough to make libintl avoid installing its own
replacement because libintl would see the define as a sign that
gnulib is happy with snprintf.  However, because gnulib didn't
enforce %1$s, users can end up with translated strings that break
when passed to the native snprintf.
(Continue reading)

Simon Josefsson | 1 Jul 19:38 2011

Re: would like to break sys_select's dependency on sys_socket

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 06/30/11 04:45, Simon Josefsson wrote:
>> Is it native Windows or MinGW?
>
> Sorry, I don't know Windows well enough to answer that question.
> For Emacs, Windows support is done completely differently:
> it doesn't use gnulib, and it is done by other people, and I
> try to avoid thinking about it as much as I can.

The reason I asked is that gnulib supports Mingw, so we shouldn't break
things for it.  However, I haven't seen anything that indicates the
dependencies you mentioned were needed on Mingw.

Anyway, I guess we'll find out eventually if someone reports a problem
for mingw.  I'll try a Windows XP mingw gnulib boot now, it was a long
time ago since I tried it.

/Simon

Ludovic Courtès | 1 Jul 22:14 2011
Picon

Re: PATH_MAX and test-stat.h

Hello,

karl <at> freefriends.org (Karl Berry) skribis:

> I am aware that conceptually there is no PATH_MAX on Hurd and no
> requirement for it to be a smallish constant, but it seems to me that
> any real-world system has to define PATH_MAX as a reasonable constant
> simply for compatibility with all the code that has been written with
> that assumption over the last 30+ years.

As you probably know, this is an instantiation of the GCS (info
"(standards) Semantics"):

  Avoid arbitrary limits on the length or number of _any_ data structure,
  including file names, lines, files, and symbols, by allocating all data
  structures dynamically.  In most Unix utilities, "long lines are
  silently truncated".  This is not acceptable in a GNU utility.

Thanks,
Ludo’.

Simon Josefsson | 2 Jul 08:44 2011

cygwin build report

Simon Josefsson <simon <at> josefsson.org> writes:

> Anyway, I guess we'll find out eventually if someone reports a problem
> for mingw.  I'll try a Windows XP mingw gnulib boot now, it was a long
> time ago since I tried it.

I meant a cygwin build..  Here is the build log:

http://autobuild.josefsson.org/gnulib/log-201107020516468723000.txt

This is on a fully up to date Windows XP and Cygwin as of 2011-07-01.
As can be seen in the log above, the build was done with "gnulib-tool
--create-testdir --with-tests --without-longrunning-tests".

First, some interesting statistics on execution time (hardware is an
atom based Dell Mini 10v laptop):

gnulib-tool: 8h47m
./configure: 48m
make: 35m
make check: 9m

The failures below seems relatively minor, so I think we are in quite
good shape.

There are two suspicious tests:

1)
./test-copy-acl.sh: line 230:  3828 Segmentation fault      (core dumped) setfacl -d group:0 tmpfile0
setfacl: illegal acl entries
(Continue reading)

Dagobert Michelsen | 2 Jul 11:18 2011

Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi,

I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and
noticed that the presence of libsigsegv is not properly detected:

> configure:9825: checking for libsigsegv
> configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc -I/opt/csw/include -m32
-xarch=386 -L/opt/csw/lib conftest.c /opt/csw/lib/libsigsegv.so -R/opt/csw/lib -lm  >&5
> "/usr/include/ia32/sys/reg.h", line 297: syntax error before or at: uint64_t

This is due to a missing include in the detection code as a definition of uint64_t
is missing. This could be solved by including inttypes.h in the testcode.

> | #define HAVE_LIBM 1
> | /* end confdefs.h.  */
> | #include <sigsegv.h>

#include <inttypes.h>   <- adding this works

> | int
> | main ()
> | {
> | sigsegv_deinstall_handler();
> |   ;
> |   return 0;
> | }

As this is the expansion of gl_LIBSIGSEGV I cc'ed bug-gnulib.

Best regards
(Continue reading)

Dagobert Michelsen | 2 Jul 12:05 2011

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi,

Am 02.07.2011 um 11:18 schrieb Dagobert Michelsen:
> I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and
> noticed that the presence of libsigsegv is not properly detected:
> 
>> configure:9825: checking for libsigsegv
>> configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc -I/opt/csw/include -m32
-xarch=386 -L/opt/csw/lib conftest.c /opt/csw/lib/libsigsegv.so -R/opt/csw/lib -lm  >&5
>> "/usr/include/ia32/sys/reg.h", line 297: syntax error before or at: uint64_t
> 
> This is due to a missing include in the detection code as a definition of uint64_t
> is missing. This could be solved by including inttypes.h in the testcode.
> 
>> | #define HAVE_LIBM 1
>> | /* end confdefs.h.  */
>> | #include <sigsegv.h>
> 
> #include <inttypes.h>   <- adding this works
> 
>> | int
>> | main ()
>> | {
>> | sigsegv_deinstall_handler();
>> |   ;
>> |   return 0;
>> | }
> 
> As this is the expansion of gl_LIBSIGSEGV I cc'ed bug-gnulib.

(Continue reading)


Gmane