asm-underscore.m4 and MSVC

The asm-underscore.m4 test currently determines #define ASM_SYMBOL_PREFIX "" but on Win32 the correct result is #define ASM_SYMBOL_PREFIX "_" The reason is that the test uses wrong command-line options to the compiler, and expects the result in a .s file - whereas 'cl' creates a file with suff

Re: MSVC support: documentation

Michael Goffioul wrote: > more to illustrate the problems I had: > - O_ACCMODE is not defined > - PATH_MAX is not defined (though stdlib.h has an equivalent _MAX_PATH) > - ending a path with double slashes lead to problems (don't remember which > ones, but Windows didn't like it) > - MSVC does not

Re: crypt not declared on more glibc versions

Reuben Thomas wrote: > Patch attached. Thanks, applied. Bruno -- In memoriam Georgi Markov

Re: crypt not declared on more glibc versions

On 10 September 2011 01:27, Bruno Haible wrote: > Reuben Thomas wrote: >> The new note in crypt.texi specifically mentions glibc 2.11; I noticed >> the problem in 2.13. > > Then it's worth changing the 3 documentation files. Care to send a patch? > (I did not want to discourage you from sending pa

Re: MSVC support: documentation

On Sun, Sep 11, 2011 at 10:23 PM, Bastien ROUCARIES wrote: >> - rename m4 test produced filesystem corruption that lead to full recheck on >> the next reboot; I had to disable the test completely > > Funny :) Do you know why this test does not do this on mingw ? No. To be honest, I didn't investi

Re: MSVC support: documentation

On Sun, Sep 11, 2011 at 11:05 PM, Michael Goffioul wrote: > On Sun, Sep 11, 2011 at 8:59 PM, Bruno Haible wrote: >> In a current situation, a number of gnulib modules compile flawlessly >> on MSVC 9. Therefore it's time to document its current status. >> >> Further fixes for this platform are, of

Re: MSVC support: documentation

On Sun, Sep 11, 2011 at 8:59 PM, Bruno Haible wrote: > In a current situation, a number of gnulib modules compile flawlessly > on MSVC 9. Therefore it's time to document its current status. > > Further fixes for this platform are, of course, welcome. BTW, you might also have a second reading of t

Re: MSVC support: documentation

On Sun, Sep 11, 2011 at 8:59 PM, Bruno Haible wrote: > In a current situation, a number of gnulib modules compile flawlessly > on MSVC 9. Therefore it's time to document its current status. > > Further fixes for this platform are, of course, welcome. For quite some time now, I've been tweaking my

Re: strings.h on MSVC

On Sun, Sep 11, 2011 at 8:24 PM, Bruno Haible wrote: >> The MSVC compiler also has no . > > And it has no strcasecmp(), strncasecmp() functions. To fix this, it's > sufficient to de-obsololetize the 'strcase' module, which provides the > replacements. You probably made my day ;) This will probabl

Re: coreutils-8.12.178-df9cd on Solaris 10

Bruno Haible wrote: > On 2011-09-04 I committed this: >> 2011-09-04 Bruno Haible >> >> acl: Improve support of NFSv4 ACLs on Solaris 10 (newer version). >> * lib/acl-internal.h (ACE_*, NEW_ACE_*): Define also on newer Solaris >> 10. >> (OLD_ALLOW, OLD_DENY): New macros. >>

MSVC support: documentation

In a current situation, a number of gnulib modules compile flawlessly on MSVC 9. Therefore it's time to document its current status. Further fixes for this platform are, of course, welcome. 2011-09-11 Bruno Haible doc: Update regarding MSVC 9. * doc/gnulib-intro.texi (Target

unistd.h on MSVC

MSVC also does not have . While the gnulib generated works around that, there are a number of configure tests which fail, merely because they contain an unconditional #include . In some cases, the fix is to write #if HAVE_UNISTD_H # include #endif instead; often or has to be included inst

Re: strings.h on MSVC

> The MSVC compiler also has no . And it has no strcasecmp(), strncasecmp() functions. To fix this, it's sufficient to de-obsololetize the 'strcase' module, which provides the replacements. 2011-09-11 Bruno Haible strcase: Support for MSVC. * modules/strcase (Status, Notice):

strings.h on MSVC

The MSVC compiler also has no . Here's a fix to avoid to include a nonexistent header file. 2011-09-11 Bruno Haible strings: Don't assume exists. * lib/strings.in.h: Include only if HAVE_STRINGS_H is 1. * m4/strings_h.m4 (gl_HEADER_STRINGS_H_BODY): Set HAVE_STRINGS_H

dirent.h on MSVC

The MSVC compilers don't have and associated functions. Here's a preliminary patch that will at least avoid to include a non-existent header file. 2011-09-11 Bruno Haible dirent: Don't assume exists. * lib/dirent.in.h: Include only if HAVE_DIRENT_H is 1. * m4/dirent

wchar.h, wctype.h: fix wint_t on MSVC

The choice of wint_t on MSVC ('unsigned short') violates ISO C 99. We need to change it to 'unsigned int' instead. 2011-09-11 Bruno Haible Fix wint_t on MSVC. * lib/wchar.in.h (wint_t): On MSVC, override it. * lib/wctype.in.h (wint_t): Likewise. * m4/stdint.m4

Re: msvc port: ensure size_t

Paul Eggert wrote: > > = lib/sys_types.in.h > > = > > /* Provide a more complete sys/time.h. > > sys/time.h -> sys/types.h Oops. Thanks for the review. Corrected like this: 2011-09-11 Bruno Haible sys_types: Fix typo.

Re: autoconf + automake support for MSVC

Den 2011-09-11 00:04 skrev Bruno Haible: > Peter Rosin wrote: >> The main benefits that I see are that you don't have to >> cross compile if you are in MSYS > > You have the wrong notion of "cross compile", if you think cross-compiling > means that $host != $build. When I am building for i386-pc-l

Re: 128-bit uid_t

On Sun, Sep 11, 2011 at 6:41 PM, Bastien ROUCARIES wrote: > n Sun, Sep 11, 2011 at 6:33 PM, Paul Eggert wrote: >> On 09/11/11 08:14, Bastien ROUCARIES wrote: >>> gcc has it : http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html >>> (at least for 64bits) >> >> I'd be leery of any attempt to def

Re: 128-bit uid_t

n Sun, Sep 11, 2011 at 6:33 PM, Paul Eggert wrote: > On 09/11/11 08:14, Bastien ROUCARIES wrote: >> gcc has it : http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html >> (at least for 64bits) > > I'd be leery of any attempt to define a system type wider than > intmax_t. For sure but we could ov

Re: msvc port: ensure size_t

On 09/11/11 09:25, Bruno Haible wrote: > = lib/sys_types.in.h = > /* Provide a more complete sys/time.h. sys/time.h -> sys/types.h

Re: 128-bit uid_t

On 09/11/11 08:14, Bastien ROUCARIES wrote: > gcc has it : http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html > (at least for 64bits) I'd be leery of any attempt to define a system type wider than intmax_t. Too many things will break. It might be OK to use __int128 for specialized internal

msvc port: ensure size_t

On MSVC 9, size_t is defined by but not by . This leads to compilation errors in strings.h and sys/uio.h, because the gnulib replacements of these files assume that defines size_t. We cannot put the replacement in , like for pid_t, because then it would collide with the size_t definition in . S

Re: 128-bit uid_t

On Sun, Sep 11, 2011 at 4:52 PM, Bruno Haible wrote: > Bastien ROUCARIES wrote: >> Did you know >> that recent mscv support a limited int128 (named __int128) under >> 64bits (limited because it does not support divide)? It is quite >> interesting in order to implement uid_t, gid because every user

Re: 128-bit uid_t

Bastien ROUCARIES wrote: > Did you know > that recent mscv support a limited int128 (named __int128) under > 64bits (limited because it does not support divide)? It is quite > interesting in order to implement uid_t, gid because every user of a > microsoft system is guranted to be mapped in a 128bi

Re: msvc port: ensure pid_t is defined

On Sun, Sep 11, 2011 at 2:18 PM, Bruno Haible wrote: > On MSVC 9, the type pid_t is nowhere defined. But POSIX wants it defined in Out of topic but interesting on this kind of subject. Did you know that recent mscv support a limited int128 (named __int128) under 64bits (limited because it does no

msvc port: ensure pid_t is defined

On MSVC 9, the type pid_t is nowhere defined. But POSIX wants it defined in This fixes it for those headers for which we have a gnulib module. I'm not sure we should create a module for ? 2011-09-11 Bruno Haible Ensure pid_t gets defined.

Re: coreutils-8.12.178-df9cd on Solaris 10

On 2011-09-04 I committed this: > 2011-09-04 Bruno Haible > > acl: Improve support of NFSv4 ACLs on Solaris 10 (newer version). > * lib/acl-internal.h (ACE_*, NEW_ACE_*): Define also on newer Solaris > 10. > (OLD_ALLOW, OLD_DENY): New macros. > (NEW_ACE_ACCESS_ALLO

Re: m4 brackets question

Hi Bruno, On 10 Sep 2011, at 16:23, Bruno Haible wrote: > Again, I've stumbled across a behaviour of brackets in autoconf macros that > I don't understand. It's just the number of nested quotation levels, with m4 processing always removing the outer level whenever text is passed through it. The