On 04/19/2017 05:13 AM, Gisle Vanem wrote:
With "%.3a %d", I do get the expected "0x1.922p+1 33".
So are these tests somewhat gcc-centric or what?
Yes. It looks to me like MSVC-2015 is right and glibc is wrong, at least
in the sense of acting like standard printf.
On 04/19/2017 09:12 AM, Tom G. Christensen wrote:
builds have now completed on Solaris 2.6 and 7
Out of curiosity, what are these old builds used for? Sun stopped
supporting Solaris 2.6 in 2006, for example.
Christian Egli wrote:
../tools/gnulib/.libs/libgnutools.a(getopt.o): In function
`process_long_option':
/home/eglic/src/liblouis/tools/gnulib/getopt.c:281: undefined reference to
`flockfile'
/home/eglic/src/liblouis/tools/gnulib/getopt.c:295: undefined reference to
`funlockfile'
collect2: err
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.
> >
> > If we add the undef's then we don't need t
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.
>
> If we add the undef's then we don't need to change anything related to
> windows_compute_revents_socket() as it'd be ca
On 19/04/17 01:28, Bruno Haible wrote:
Tom G. Christensen wrote:
On Solaris 2.6 and 7 there is the additional issue of missing MAP_ANONYMOUS:
In file included from vma-iter.c:41:0:
/usr/include/sys/procfs.h:44:2: error: #error "Cannot use procfs in the
large file compilation environment"
vma-it
On 19/04/17 01:05, Bruno Haible wrote:
Tom G. Christensen wrote:
This is causing my daily gnulib builds to fail on Solaris.
On Solaris 8 and 9 I'm seeing this error:
In file included from vma-iter.c:41:0:
/usr/include/sys/procfs.h:44:2: error: #error "Cannot use procfs in the
large file compil
Hi all
I'm using the latest checkout from gnulib an I'm trying to upgrade to
it. However when I cross-compile my project under mingw I get a
compilation error in gnulib/getopt.c:
i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../liblouis -I../liblouis
-I../tools/gnulib -I../tools/gnulib -g -O2 -W
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 calling
> > FD_TO_SOCKET() and getti
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 calling
> FD_TO_SOCKET() and getting INVALID_SOCKET back. This is propagated back
> to windows_compute_revent
When using MSVC-2015 to build the tests/unistdio/test-ulc-*.c files,
I get ASSERT() on all the '%a' formats. E.g. in
unistdio/test-ulc-vasnprintf1.exe
and unistdio/test-ulc-printf1.h (line 195):
char *result =
my_xasprintf ("%a %d", 3.1416015625, 33, 44, 55);
ASSERT (result != NULL
11 matches
Mail list logo
