Re: dup2 mingw failure

Eric Blake writes: > According to Simon Josefsson on 1/8/2010 2:36 AM: >> I got this on MinGW: >> >> test-dup2.c:140: assertion failed >> FAIL: test-dup2.exe > > I wish mingw had a better version number reporting scheme. I can't > reproduce the failure when I cross-compile from cygwin to mingw,

Re: ls.c doesn't compile

Sorry for my misunderstanding ! Attached is /usr/include/bits/sigcontext.h Line 28 includes , also attached as asm_sigcontext.h Le 08/01/2010 18:03, Eric Blake a écrit : > According to Jean Philippe EIMER on 1/8/2010 9:49 AM: >> Attached is a patch for ls.c, and below lines of context around erro

Re: ls.c doesn't compile

Jean Philippe EIMER wrote: > > Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1 and > > kernel 2.6.32.3 : > > > > In file included from /usr/include/bits/sigcontext.h:28, > > from /usr/include/signal.h:339, > > from ../lib/signal.h:34, > >

Fwd: stat-time LGPL

Hi Paul and James, The lib/stat-time.h file that you contributed to gnulib is under GPL. Guile would like to use it (see attached mail), but Guile is LGPL. Can you agree to relicensing this file under LGPL? Bruno Forwarded message Subject: stat-time LGPL

stat-time LGPL

Hi, Guile needs some way of dealing with nanosecond timestamps in stat structures. stat-time looks like the right thing but it is GPL. It depends on time and extensions, which are both LGPLv2+. Can stat-time be made lgpl? Thanks, Andy

Re: ls.c doesn't compile

According to Jean Philippe EIMER on 1/8/2010 9:49 AM: > Attached is a patch for ls.c, and below lines of context around error : Thanks. Let's keep the list in the loop, please. > CC ls.o > In file included from /usr/include/bits/sigcontext.h:28, > from /usr/include/signa

Re: maint.mk vs. PRAGMA_SYSTEM_HEADER

According to Jim Meyering on 1/8/2010 6:22 AM: >> +# Add an exemption for sc_makefile_check. >> +_makefile_check_exceptions = ' && !/^cu_install_program =/' > > Both look fine. Thanks! > I did feel a little guilty back when I moved that rule with its > coreutils-specific exception into gnulib ;-)

Re: ls.c doesn't compile

[adding bug-gnulib] According to Jean Philippe EIMER on 1/8/2010 3:08 AM: > Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1 and > kernel 2.6.32.3 : > > In file included from /usr/include/bits/sigcontext.h:28, > from /usr/include/signal.h:339, >

Re: dup2 mingw failure

According to Simon Josefsson on 1/8/2010 2:36 AM: > I got this on MinGW: > > test-dup2.c:140: assertion failed > FAIL: test-dup2.exe I wish mingw had a better version number reporting scheme. I can't reproduce the failure when I cross-compile from cygwin to mingw, then run the program natively o

Re: maint.mk vs. PRAGMA_SYSTEM_HEADER

Eric Blake wrote: > According to Bruno Haible on 1/7/2010 2:27 PM: >> Eric Blake wrote: >>> This syntax is necessary, though. PRAGMA_SYSTEM_HEADER is currently either >>> empty, or equal to '#pragma GCC system_header' ... >> >> Another case where @IDENTIFIER@ has to be used instead of $(IDENTIFIER

open MinGW failure

I got this when cross-compiling to MinGW with Wine: test-open.h:34: assertion failed FAIL: test-open.exe The relevant code is: /* Cannot create directory. */ errno = 0; ASSERT (func ("nonexist.ent/", O_CREAT | O_RDONLY, 0600) == -1); Open returns 3 for me, and it has created a file 'none

dup2 mingw failure

I got this on MinGW: test-dup2.c:140: assertion failed FAIL: test-dup2.exe The relevant code is: /* The destination must be valid. */ errno = 0; ASSERT (dup2 (fd, -2) == -1); Debugging this, it seems MinGW dup2 returns -2 in this situation. Any ideas? Is -2 a valid file descriptor on M

Re: extern "C" for glob.h

Hi John, John W. Eaton wrote: > In glob.in.h, we have > ... > > #ifndef __BEGIN_DECLS > # define __BEGIN_DECLS > # define __END_DECLS > #endif > > If HAVE_SYS_CDEFS_H is 0, then __BEGIN_DECLS and __END_DECLS are > likely undefined. To be C++ friendly, I think this should changed as >