wcwidth on mingw

Similarly for wcwidth, I'm seeing this error: ../gllib/wchar.h:678: error: `wcwidth' was not declared in this scope Here too the problem is that gnulib defines a function rpl_wcwidth, although wcwidth does not exist on mingw. gnulib could just define wcwidth instead. This fixes it: 2010-04-0

Re: nanosleep on mingw

Hi Jim, > Though note that the patches to modules/time and m4/time_h.m4 > did not apply and I did them manually. Yes, I was constantly changing the same parts of these two files. > Please apply. Applied. Bruno

Re: timegm on mingw

Bruno Haible wrote: > A similar error for timegm, in the C++ tests on mingw: > > ../gllib/time.h:448: error: `timegm' was not declared in this scope > > Again, we need to distinguish the case of a missing function from the > case of a broken function. > > m4/time_h.m4 contains some dubious code:

Re: nanosleep on mingw

Bruno Haible wrote: > Similarly, on mingw with warn-on-use.h modified to work like if g++ >= 4.3 > were present, I'm seeing this error: > > ../gllib/time.h:359: error: `nanosleep' was not declared in this scope > > It would also be an error on the other platforms lacking nanosleep, > with g++ 4.3

strptime on mingw

Another error in C++ mode on mingw: ../gllib/time.h:433: error: `strptime' was not declared in this scope The reason is a mistake that I made on 2010-03-08, because the macro name REPLACE_STRPTIME and the "#define strptime rpl_strptime" made me think an existing function was being replaced. Thi

timegm on mingw

A similar error for timegm, in the C++ tests on mingw: ../gllib/time.h:448: error: `timegm' was not declared in this scope Again, we need to distinguish the case of a missing function from the case of a broken function. m4/time_h.m4 contains some dubious code: If timegm exists and mktime works

localtime_r on mingw

Still on mingw, I'm seeing these errors: ../gllib/time.h:394: error: `localtime_r' was not declared in this scope ../gllib/time.h:409: error: `gmtime_r' was not declared in this scope Same problem: The m4 macros don't distinguish a missing function from a broken system function. This fixes it

time_r: small updates

This fixes minor issues with the time_r module: not mentioned in the documentation, imprecise module description, unnecessary include. 2010-04-03 Bruno Haible time_r: Minor updates. * modules/time_r (Description): Mention the provided functions. * lib/time_r.c: Don't i

time: fix regression

This fixes a bad copy&paste mistake I did three weeks ago: 2010-04-03 Bruno Haible time: Fix regression introduced on 2010-03-08. * m4/time_h.m4 (gl_TIME_MODULE_INDICATOR): Require gl_HEADER_TIME_H_DEFAULTS, not gl_HEADER_STRING_H_DEFAULTS. --- m4/time_h.m4.orig Sat

[PATCH] maint.mk: don't silently disable project-specific syntax-check rules

I realized that the recent variable name change was actually rather insidious. It would silently disable project-specific syntax-check rules that used the old name. That made it very likely that someone would not notice, and would never upgrade to use the new name, _sc_search_regexp. This new de

nanosleep on mingw

Similarly, on mingw with warn-on-use.h modified to work like if g++ >= 4.3 were present, I'm seeing this error: ../gllib/time.h:359: error: `nanosleep' was not declared in this scope It would also be an error on the other platforms lacking nanosleep, with g++ 4.3. Again, to fix this, one needs

fchdir on mingw

On mingw still, I'm seeing these errors: test-fchdir.c:24: error: `fchdir' undeclared here (not in a function) make[4]: *** [test-fchdir.o] Error 1 and in C++ mode: ../gllib/unistd.h:698: error: `fchdir' was not declared in this scope The reason is a regression from 2010-03-08: I was conf

getpagesize on mingw

Similarly, I'm seeing this error in C++ mode on mingw: ../gllib/unistd.h:1042: error: `getpagesize' was not declared in this scope This fixes it: 2010-04-03 Bruno Haible getpagesize: Fix C++ test error on mingw. * lib/unistd.in.h (getpagesize): Don't use _GL_CXXALIASWARN i

getline on mingw

A different case is this error: ../gllib/stdio.h:803: error: `getline' was not declared in this scope Here we really want to do "#define getline rpl_getline" even if the system does not declare the function, for the reason mentioned in the documentation: "Some platforms provide a function by

ftello on mingw

Likewise for the function: ../gllib/stdio.h:699: error: `ftello' was not declared in this scope This should fix it: 2010-04-03 Bruno Haible ftello: Fix C++ test error on mingw. * lib/stdio.in.h (ftello): Use modern idiom. * m4/ftello.m4 (gl_FUNC_FTELLO): Distinguis

fseeko on mingw

Similarly for the fseeko function on mingw. I'm seeing this error: ../gllib/stdio.h:632: error: `fseeko' was not declared in this scope This should fix it. 2010-04-03 Bruno Haible fseeko: Fix C++ test error on mingw. * lib/stdio.in.h (fseeko): Use modern idiom. * m

mkstemp on mingw

Similarly for the mkstemp function: I'm seeing this error: ../gllib/stdlib.h:600: error: `mkstemp' was not declared in this scope > Here it becomes necessary to distinguish the two cases, like we do for many > other functions. Likewise here. This fixes it. 2010-04-03 Bruno Haible

Re: wdiff-0.6.1 build problems

Hi Martin, > > On Solaris 7 SPARC, compilation with cc fails like this: > > > > cc -DHAVE_CONFIG_H -I. -I.. -DDEFAULT_TEXT_DOMAIN=\"wdiff-gnulib\" > > -I../intl -I/usr/local/include -I/usr/local/include -c localcharset.c > > "./getopt.h", line 31: empty file name > > cc: acomp f

stpncpy on mingw

On mingw, with warn-on-use.h modified to simulate a gcc >= 4.3, I'm seeing this error: In file included from test-string-c++.cc:22: ../gllib/string.h:525: error: `stpncpy' was not declared in this scope The reason is that the 'stpncpy' module uses #define stpncpy rpl_stpncpy both in the cas

lchmod on mingw

On mingw, the C++ tests give this error: ../gllib/sys/stat.h:659: error: invalid conversion from `int (*)(const char*, int)' to `int (*)(const char*, mode_t)' The reason is that the 'chmod' function in mingw has an 'int' as second argument type. This fixes it: 2010-04-03 Bruno Haible

Re: openpty and mingw

And a related doc update is this one: 2010-04-03 Bruno Haible pty: Update doc. * doc/glibc-headers/pty.texi: Mention changes done since 2010-03-18. --- doc/glibc-headers/pty.texi.orig Sat Apr 3 12:37:37 2010 +++ doc/glibc-headers/pty.texi Sat Apr 3 12:36:26 2010 @@ -25

getcwd on mingw

On mingw, I'm seeing this error in the C++ namespace tests: ../gllib/unistd.h:794: error: invalid conversion from `char*(*)(char*, int)' to `char*(*)(char*, size_t)' This should fix it: 2010-04-03 Bruno Haible unistd: Fix C++ test error on mingw. * lib/unistd.in.h (getcwd):

openpty and mingw

The pty/tty functions are not yet ported to mingw. (Native Windows does not have ttys, not even a .) This fixes the doc: 2010-04-03 Bruno Haible * doc/glibc-functions/openpty.texi: Update regarding mingw. * doc/glibc-functions/login_tty.texi: Likewise. * doc/glibc-func

c-strtold compilation failure on mingw

On mingw, I'm seeing this compilation error: gcc-3 -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -DNO_XMALLOC -DEXEEXT=\".exe\" -I. -I.. -I../intl -I/usr/local/mingw/include -Wall -g -O2 -MT c-strtold.o -MD -MP -MF $depbase.Tpo -c -o c-strtold.o c-strtold.

Re: duplocale cygwin failure

Hi Simon, > In file included from test-locale-c++.cc:22: > ../gllib/locale.h:329: error: ‘duplocale’ was not declared in this scope > ../gllib/locale.h:329: error: invalid type in declaration before ‘;’ token > make[3]: *** [test-locale-c++.o] Error 1 > make[3]: Leaving directory `/home/Simon/gnul

Re: Failed test-localename 64-bit OS X 10.6.2

Hello, Panu Kekäläinen wrote, in reply to : > After applying the patch the test results are: > > All 320 tests passed > > > Thank you for the fast response! Thanks to you! I very m

Re: [wdiff-bugs] wdiff-0.6.1 build problems

Hi there! Nelson H. F. Beebe reports problems building Gnulib sources shipped with wdiff 0.6.1. Those sources should be up to date, so current git should exhibit these problems as well. On 02.04.2010 20:58, Nelson H. F. Beebe wrote: > On Solaris 7 SPARC, compilation with cc fails like this: > >

Re: gnulib-tool: Ensure that long-running tests are executed last

Bruno Haible wrote: > Hi Eric, Jim, > >> >> This ensures that long-running tests are executed last. So that the user >> >> gets the maximum of information as quickly as possible. >> > >> > That goes counter to the idea of parallel execution, where you want the >> > long-running tests front-loaded s

Re: gnulib-tool: Ensure that long-running tests are executed last

Hi Bruno, * Bruno Haible wrote on Sat, Apr 03, 2010 at 12:13:12AM CEST: > - I was assuming a sequential execution (since this is the default with > "make") and the goal of maximizing the information that is available > within a short time after starting the test. Your goal is worthy but