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 looking at that
Hi Eric,
2011-10-19 Eric Blake ebl...@redhat.com
+ 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
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;
- /*
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 require libgnu.a
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.
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 I'm the
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=1
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:
#
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
then gettextize
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 configure.ac is a
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
release is out?
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 version 0.19 - because
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.
This -Iintl
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 make
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:
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
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html
explicitly talks about what rmdir()
Paul Eggert egg...@cs.ucla.edu 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
http://multitheftauto.googlecode.com/svn/trunk/vendor/curl/packages/OS400/README.OS400.
Android
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
Bruno Haible br...@clisp.org 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_* functions
On Minix 3.1.8, there are several issues:
1) openpty() exists in libutil, but its declaration in util.h is #ifdefed
out.
2) util.h is not self-contained, you need to write
#include stdarg.h
#define _BSD_VA_LIST_ va_list
#include util.h
3) openpty() fails with error code ENOENT.
Simon, Paul,
Android users are constantly worrying about whether to compile
with -fno-short-enums, citing ABI incompatibilities. E.g., see
http://osdir.com/ml/android-ndk/2010-10/msg00559.html.
Thanks for this information. I feared that the old assumption enum =
int that I have relied
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
/* In C++ we avoid
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
file
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 it
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
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.
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
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:
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 br...@clisp.org
unlockpt: Detect invalid argument.
* lib/unlockpt.c: Include fcntl.h.
(unlockpt): Check whether
Eric Blake wrote:
+2011-10-17 Eric Blake ebl...@redhat.com
+
+ 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.
+
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
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
32 matches
Mail list logo
