Re: a saner bootstrap script

Hi Bruno, On 21 Oct 2011, at 06:58, Bruno Haible wrote: > Gary V. Vaughan wrote: >> On the other hand, if by "incremental" you really mean chunking my rewrite >> into >> patches that add a function here and there, and disable bits of the old >> script >> when they are no longer called, then I co

[PATCH] README-release improvements

I made these changes in gnulib-local/top/README-release while making a start at leveraging the gnulib release machinery into GNU Libtool, but they seem generally applicable too. Okay to push? (NOTE: I doubt this will work with `git apply-patch` since I pasted it together from bits of manual diffs

Re: enum vs int and API/ABI compatibility

On 10/20/11 12:57, Simon Josefsson wrote: > It's still not clear to me that my proposed change would break on even > OS/400 though, it seems the curl problem was only about varargs? Yes, that's right. I don't have any smoking gun here. Just suspicions. But I guess you're OK on the major platform

Re: bug#9813: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/11 17:06, Eric Blake wrote: >> So far, I've seen only Cygwin mentioned. >> Where does it happen in a typical GNUish environment? > > Try the same exercise using NFSv2 or NFSv3 mounts I don't see why NFSv3 or v3 would be different. I just tried your test case with an NFSv3 mount (RHEL 5.7

Re: [PATCH] posix_openpt: new module

Eric Blake wrote: > +2011-10-17 Eric Blake > + > + posix_openpt: new module > + * modules/posix_openpt: New module. > + * m4/posix_openpt.m4: New file. > + * lib/posix_openpt.c: Likewise. > + * m4/stdlib_h.m4 (gl_STDLIB_H): Check for decl. > + (gl_STDLIB_H_DEFAULTS): Set

unlockpt and EBADF

Our unit test verifies that unlockpt() checks against an invalid argument. But gnulib's implementation does not always do this check. 2011-10-20 Bruno Haible unlockpt: Detect invalid argument. * lib/unlockpt.c: Include . (unlockpt): Check whether fd is valid, using fcn

openpty: fix for AIX

On AIX 6.1, I'm seeing this compilation failure: gcc -mlong-double-64 -D_ALL_SOURCE -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -Wall -g -O2 -MT openpty.o -MD -MP -MF .deps/openpty.Tpo -c -o openpty.o openpty.c openpty.c:50: error: conflicting types for 'openpty' ./pty.h:407: error: p

Re: bug#9813: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/2011 06:06 PM, Eric Blake wrote: Try the same exercise using NFSv2 or NFSv3 mounts (NFSv4 is getting closer to POSIX compliance, but I don't know if it will handle this any better). I suspect that it would be possible to find a testcase under Linux and Solaris clients using a less-than-s

Re: a saner bootstrap script

On 10/20/2011 05:58 PM, Bruno Haible wrote: Gary V. Vaughan wrote: On the other hand, if by "incremental" you really mean chunking my rewrite into patches that add a function here and there, and disable bits of the old script when they are no longer called, then I could be persuaded to do that.

Re: bug#9813: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/2011 05:46 PM, Paul Eggert wrote: It's more than just cygwin. So far, I've seen only Cygwin mentioned. Where does it happen in a typical GNUish environment? Try the same exercise using NFSv2 or NFSv3 mounts (NFSv4 is getting closer to POSIX compliance, but I don't know if it will ha

Re: a saner bootstrap script

Gary V. Vaughan wrote: > On the other hand, if by "incremental" you really mean chunking my rewrite > into > patches that add a function here and there, and disable bits of the old script > when they are no longer called, then I could be persuaded to do that. That would be a way to proceed. But i

Re: bug#9813: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/11 12:57, Eric Blake wrote: > That's because it's a shall fail, not a may fail error: > > [EBUSY] > The directory to be removed is currently in use by the system > or some process and the implementation considers this to be an error. But "in use by" does not mean "accessed by an open fil

Re: enum vs int and API/ABI compatibility

Simon Josefsson asked: > > 2) Change the argument type of idna_strerror to 'int'. > > Change the enum from > > > > typedef enum { > >... > >IDNA_ICONV_ERROR = 9, > >... > > } Idna_rc; > > > >to > > > > typedef int Idna_rc; > > #ifdef __cplusplus > >

Re: enum vs int and API/ABI compatibility

Simon, Paul, > > Android users are constantly worrying about whether to compile > > with -fno-short-enums, citing ABI incompatibilities. E.g., see > > . > > Thanks for this information. I feared that the old assumption "enum = > int" that I

posix_openpt on Minix

On Minix 3.1.8, there are several issues: 1) openpty() exists in libutil, but its declaration in is #ifdefed out. 2) is not self-contained, you need to write #include #define _BSD_VA_LIST_ va_list #include 3) openpty() fails with error code ENOENT. 4) When I add this code to

Re: enum vs int and API/ABI compatibility

Bruno Haible writes: > Hi Simon, > >> silence C++ warnings ... >> >> typedef enum >> { >> ... >> } Idna_rc; >> ... >> extern IDNAPI const char *idna_strerror (Idna_rc rc); >> >> ... allows future C++ code to be warning free. > > It was said that the root problem is that your idna_* func

Re: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/2011 01:47 PM, Paul Eggert wrote: On 10/20/11 10:38, Eric Blake wrote: POSIX is clear that attempts to rmdir() a directory that still has open descriptors may fail. Hmm, that's news to me. And on the contrary, the spec

Re: enum vs int and API/ABI compatibility

Paul Eggert writes: > On 10/19/11 04:06, Simon Josefsson wrote: >> 1) Is there any platform where this has any implications for the ABI? > > OS/400. libcurl ran into this problem; see > . > > Android users ar

Re: rm -rf calls rmdir() prior to close(), which can fail

On 10/20/11 10:38, Eric Blake wrote: > POSIX is clear that attempts to rmdir() a directory that still has open > descriptors may fail. Hmm, that's news to me. And on the contrary, the spec explicitly talks about what rmdir()

rm -rf calls rmdir() prior to close(), which can fail

POSIX is clear that attempts to rmdir() a directory that still has open descriptors may fail. Of course, on Linux, this (rather limiting) restriction is not present, so we don't notice it; but on Cygwin, there are certain file systems where this is a real problem, such as in this thread: http

Re: a saner bootstrap script

Gary V. Vaughan wrote: ... > On the other hand, if by "incremental" you really mean chunking my rewrite > into > patches that add a function here and there, and disable bits of the old script > when they are no longer called, then I could be persuaded to do that. How > big should the chunks be to

Re: a saner bootstrap script

Hi Jim, On 20 Oct 2011, at 23:44, Jim Meyering wrote: > Gary V. Vaughan wrote: >> On 19 Oct 2011, at 20:13, Jim Meyering wrote: >>> Gary V. Vaughan wrote: > Jim, please consider pulling it into coreutils master as a better fix than > twidding Makefiles after the fact in bootstrap.conf. >>>

Re: a saner bootstrap script

Gary V. Vaughan wrote: > On 19 Oct 2011, at 20:13, Jim Meyering wrote: >> Gary V. Vaughan wrote: Jim, please consider pulling it into coreutils master as a better fix than twidding Makefiles after the fact in bootstrap.conf. > This -Iintl option will disappear with gettext versio

Re: a saner bootstrap script

Ping? On 16 Oct 2011, at 12:50, Gary V. Vaughan wrote: > Hi Jim, > > On 16 Oct 2011, at 04:15, Jim Meyering wrote: >> Gary V. Vaughan wrote: >>> Is there anything else I can do to help you incorporate this, and the >>> matching bootstrap.conf I wrote for you into coreutils now that the >>> releas

[PATCH] Fix coreutils -Iintl vs gnulib gettext [WAS Re: a saner bootstrap script]

Ping? On 16 Oct 2011, at 18:28, Gary V. Vaughan wrote: > On 16 Oct 2011, at 15:58, Bruno Haible wrote: >> Gary V. Vaughan wrote: >>> If there is a bug in gnulib-tool, or autopoint that puts unnecessary >>> 'intl/' references into Makefiles when the presence of >>> AM_GNU_GETTEXT_VERSION in configu

Re: a saner bootstrap script

Hi Jim, On 19 Oct 2011, at 20:13, Jim Meyering wrote: > Gary V. Vaughan wrote: >>> Jim, please consider pulling it into coreutils master as a better fix than >>> twidding Makefiles after the fact in bootstrap.conf. >>> This -Iintl option will disappear with gettext version 0.19 - because >>>

posix_openpt on OpenBSD

On OpenBSD 4.9, I get these test results: PASS: test-openpty test-posix_openpt.c:52: assertion failed FAIL: test-posix_openpt On this platform, gnulib replaces openpty (thin wrapper) and posix_openpt (new implementation). But it fails because there is no /dev/ptmx. Adding this workaround: # if

Re: pt_chown linking

I wrote: > if your main gnulib-tool invocation is with --libtool, > use gnulib-tool a second time, without --libtool and just just one > module: 'pt_chown'. The first gnulib-tool invocation should use --avoid=pt_chown. This currently fails: gcc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=

Re: [PATCH] posix_openpt: new module

Jim Meyering wrote: > diff --git a/lib/posix_openpt.c b/lib/posix_openpt.c > index 3b7d4cf..19cd0b6 100644 > --- a/lib/posix_openpt.c > +++ b/lib/posix_openpt.c > @@ -46,5 +46,3 @@ posix_openpt (int flags) > >return master; > } > - > -#endif Another pretty basic failure, that makes me think

Re: [PATCH] posix_openpt: new module

Eric, > > * doc/posix-functions/posix_openpt.texi: Mention ENOENT error code. > > Which platforms failed with ENOENT? On those platforms that don't have posix_openpt() already, except AIX and native Windows, you attempt to open /dev/ptmx. If it does not exist, the function fails with ENOENT.

Re: pt_chown linking

Eric Blake wrote: > > CCLD libgnu.la > > CC pt_chown.o > > make[4]: *** No rule to make target `libgnu.a', needed by `pt_chown'. Stop. > > > > Looks like the gnulib-tool output is not considering the possibility of > > libtool mixing with the creation of pt_chown. > > Changing pt_chown to not requ

Re: [PATCHv2 2/2] pt_chown: break gnulib link dependency

Eric, > diff --git a/lib/pt_chown.c b/lib/pt_chown.c > index ccc04fd..f654b2d 100644 > --- a/lib/pt_chown.c > +++ b/lib/pt_chown.c > @@ -30,22 +30,18 @@ > > static int > -do_pt_chown (void) > +do_pt_chown (char *pty) > { > - char *pty; >struct stat st; >struct group *p; >gid_t gid;

Re: [PATCHv2 1/2] grantpt: only build pt_chown when needed

Hi Eric, > 2011-10-19 Eric Blake > > + grantpt: only build pt_chown when needed > + * modules/pt_chown: Delete, merging into... > + * modules/grantpt: ...its sole user. Make building of pt_chown > + depend on an automake conditional. > + * gnulib-tool (func_get_automake_s

Re: license relaxation request

ons 2011-10-19 klockan 17:30 -0600 skrev Eric Blake: > On 10/19/2011 04:28 PM, Bruno Haible wrote: > > Hi Eric, > > > >> Would you mind also relaxing the license on openpty() to LGPLv2+, now > >> that all its components have been relaxed? > > > > This one is fine with me as well. > > Huh - in look