If chdir is a problem, why not using a heavy weight approach (better safe
than sorry particularly if gnulib is used for a lot of project):
- fork and exec an helper for name resolution
- pass fd using a socket
It is really heavy but it is on the safe side
Bastien
Le 23 déc. 2010 03:12, "Paul Egg
Eric Blake wrote:
> On 12/22/2010 03:19 PM, Jim Meyering wrote:
>> Bruno Haible wrote:
>>
>>> Ping? No one wants to solve this? It's a critical issue for libposix.
>>>
>>> Eric Blake wrote:
error() is not POSIX. Maybe the thing to do is figure out what in
libposix is dragging in error(),
Hi Bruno
OK, a couple of problems:
During compile of gllib:
NSIG missing, I added it to gllib/spwani.c, in a brute force fashion (#define
NSIG 32) without really know what I'm doing here...
"/bin/kill -l | wc -w" returns 33.
During compile of gltests:
Something very weird errors in test-allig
Hi Paul,
> > For example, if save_cwd called
> > currdir_fd = open (".");
> > then on a platform that supports fchdir() natively [not gnulib's
> > emulation], a failure to do fchdir (currdir_fd) is of type (a).
> > It can only occur if some other part of the program did side
> > effects on cur
Bastien ROUCARIES wrote:
> If chdir is a problem, why not using a heavy weight approach (better safe
> than sorry particularly if gnulib is used for a lot of project):
> - fork and exec an helper for name resolution
> - pass fd using a socket
>
> It is really heavy but it is on the safe side
I li
Hello Joachim,
Please, let's use different mails with different subject for each topic.
Otherwise I cannot keep track which issues have been dealt with, and
the conversation dies down in confusion.
> During compile of gllib:
> NSIG missing, I added it to gllib/spwani.c, in a brute force fashion
Joachim Schmitz wrote:
> During compile of gltests:
> Something very weird errors in test-allignof.c:
> source='test-alignof.c' object='test-alignof.o' libtool=no DEPDIR=.deps
> depmode=none /bin/sh ./../build-aux/depcomp cc -DHAVE_CONFIG_H -I.
> -DGNULIB_STRICT_CHECKING=1 -I. -I. -I.. -I./.
Joachim Schmitz wrote:
> alphasort missing, need to modify gllib/dirent.in.h? How?
> source='test-dirent-c++.cc' object='test-dirent-c++.o' libtool=no
> DEPDIR=.depsdepmode=none /bin/sh ./../build-aux/depcomp c++ -HAVE_CONFIG_H
> -I. -DGNULIB_STRICT_CHECKING=1 -I. -I. -I.. -I./.. -I../glli
Joachim Schmitz wrote:
> gethostname missing (resp. not found, it is available and declared in
> ), in various places. I added it to gllib/unistd.in.h
> source='test-fcntl-h-c++.cc' object='test-fcntl-h-c++.o' libtool=no
> DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp c++ -DHAVE_CONF
Joachim Schmitz wrote:
> Problem with HOST_NAME_MAX (MAXHOSTNAMELEN is set to 64 in ,
> added this to gllib/unistd.in.h, but don't think it belongs there):
> char buf[HOST_NAME_MAX];
> ^
> "/usr/local/Floss/gnulib/testdir-posix/gltests/test-gethostname.c", line 38:
> error(163):
>
Joachim Schmitz wrote:
> Our select() needs (for fd_set and friends), I added this to
> gllib/sys_select.in.h
gnulib's lib/sys_select.in.h already contains an inclusion of .
What was the symptom that you observed?
Bruno
Joachim Schmitz wrote:
> rpl_printf missing (during linking) (and an empty .o file created)
> ERROR [1210]:
> test-stdio-c++.o (.rodata + 0x10): unresolved reference to rpl_printf.
Hmm, an empty .o file indicates some other kind of error. Is it
reproducible when you try to build print
Hi Bruno
OK, the highest number for any SIG is 31, so NSIG should really be
32.
The only SA_ Macros I can find are SA_DATA_SITE in ,
most probably unrated, and SA_NOCLDSTOP and SA_RESERVED_31 in , and
nothing that looks remotely like a replacement, signal.h attached
Bye, Jojo
-Original M
Oh well, it is not here. So some kind of workaround is needed.
-Original Message-
From: Bruno Haible [mailto:br...@clisp.org]
Sent: Thursday, December 23, 2010 1:43 PM
To: Joachim Schmitz
Cc: bug-gnulib@gnu.org
Subject: Re: gethostname on HP-NonStop
Joachim Schmitz wrote:
> gethostname m
Good question. In config.h I can only see:
#define HOST_NAME_MAX
So it gets #define'd but with no value
>From config.log:
configure:33394: checking for HOST_NAME_MAX
configure:33420: cc -o conftest -g -I/usr/local/include conftest.c >&5
static long int longval () { return MAXHOSTNAMELEN; }
Bastien ROUCARIES wrote:
> If chdir is a problem, why not using a heavy weight approach (better safe than
> sorry particularly if gnulib is used for a lot of project):
> - fork and exec an helper for name resolution
> - pass fd using a socket
>
> It is really heavy but it is on the safe side
Expen
Yes, but with a condition that apparently is not met (and to deeply nested and
complicated for me to grasp), hence my change:
diff -u ./gllib/sys_select.in.h.orig ./gllib/sys_select.in.h
--- ./gllib/sys_select.in.h.orig2010-10-10 16:05:05.0 -0500
+++ ./gllib/sys_select.in.h 20
Hi Bruno
test-stdio-c++.o was the empty file
gllig/printf.o is not, but does not contain rpl_printf:
$ nm -Pe gllib/printf.o
E __stdio_fp
F printf
E rpl_vfprintf
Bye, Jojo
-Original Message-
From: Bruno Haible [mailto:br...@clisp.org]
Sent: Thursday, December
You mean add alphasort to gllib/dirent.in.h?
We don't have an alphasort elsewhere
And yes, we're quite a bit behind the current POSIX...
-Original Message-
From: Bruno Haible [mailto:br...@clisp.org]
Sent: Thursday, December 23, 2010 1:40 PM
To: Joachim Schmitz
Cc: bug-gnulib@gnu.org
Sub
Joachim Schmitz wrote:
> Incompatible prototype for inet_ntop
> source='test-getaddrinfo.c' object='test-getaddrinfo.o' libtool=no
> DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp cc -DHAVE_CONFIG_H
> -I. -DGNULIB_STRICT_CHECKING=1 -I. -I. -I.. -I./.. -I../gllib
> -I./../gllib
Mine was:
diff -u ./gllib/unistd.in.h.orig ./gllib/unistd.in.h
--- ./gllib/unistd.in.h.orig2010-12-20 19:57:37.0 -0600
+++ ./gllib/unistd.in.h 2010-12-23 07:57:13.0 -0600
@@ -51,6 +51,14 @@
# undef _GL_INCLUDING_WINSOCK2_H
#endif
+#ifdef __TANDEM /* HP-Nonstop has gethostname
Bastien ROUCARIÈS wrote:
> We could amortize the fork daemonize the daemon only once but we must
> care about security... but i could be done if fork is prohibitive.
Starting a daemon...
Yes, that sounds challenging.
> Unfortunatly context switching is the main cost so, i expext a heavy use
>
> H
Libfloss is not used (yet?), but has some hooks for this problem, the compiler
wrapper script it contains uses -DSOCKLEN_T=socklen_t.
Other than that socklen_t is typedef'ed in (and as an int) but,
for some strange and probably historical reason, not used anywhere, in
particular not in those s
My fix for NSIG:
diff -u ./gllib/signal.in.h.orig ./gllib/signal.in.h
--- ./gllib/signal.in.h.orig2010-10-10 16:05:05.0 -0500
+++ ./gllib/signal.in.h 2010-12-23 06:52:43.0 -0600
@@ -73,7 +73,7 @@
#if @GNULIB_SIGPROCMASK@
-# if !...@have_posix_signalblocking@
+# if !...@have_p
On 12/23/2010 05:30 AM, Bruno Haible wrote:
> Hello Joachim,
>
> Please, let's use different mails with different subject for each topic.
> Otherwise I cannot keep track which issues have been dealt with, and
> the conversation dies down in confusion.
Also, it would be nice if you didn't top-post
On 12/23/2010 05:08 AM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> If chdir is a problem, why not using a heavy weight approach (better safe
>> than sorry particularly if gnulib is used for a lot of project):
>> - fork and exec an helper for name resolution
>> - pass fd using a socket
>>
>>
Here's one of those CHECK macros expanded
typedef struct { char slot1; char slot2; } char_helper; extern int (*
verify_function40 (void)) [(! !sizeof (struct { unsigned int
verify_error_if_negative_size__: (((size_t)__INTADDR__(&(((struct { char
__slot1; char __slot2; } *)0)->__slot2))) ==
((s
* modules/sigpipe (License): Relax license.
Signed-off-by: Eric Blake
---
Right now, the sigpipe module depends only on:
signal
sigprocmask
stdio
unistd
all of which are LGPLv2+. It also adds a single file, m4/sigpipe.m4,
which is under the permissive .m4 file license. Therefore, since
there
On 12/23/10 06:52, Eric Blake wrote:
> Unfortunately, it is not possible to pass fds on cygwin; it is not
> possible to implement SCM_RIGHTS on top of what Windows provides. Then
> again, cygwin's *at functions don't need replacing, so it's a moot
> point. The whole exercise here is how to cater
For cygwin and windows plateform see ntcreatefile that allow to open an
handle relativly to another handle
Bastien
Le 23 déc. 2010 15:52, "Eric Blake" a écrit :
On 12/23/2010 05:08 AM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> If chdir is a problem, why...
Unfortunately, it is not possi
Dear bruce,
See my attempt to provide program name under aix hpux and irix,
If you could test it, i could help you
Btw instead of creating our own interface why not use the well known bsd
interface?
Getprogname() and setprogname()?
Bastien
Le 23 déc. 2010 18:19, "Bruce Korb" a écrit :
On 12
On 12/23/2010 10:44 AM, Bastien ROUCARIES wrote:
Bastien, can you please convince your mailer to preserve threading? Thanks.
> For cygwin and windows plateform see ntcreatefile that allow to open an
> handle relativly to another handle
Yes, cygwin's already using that. Whether it makes sense t
Le jeudi 23 décembre 2010 18:58:37, vous avez écrit :
> On 12/23/2010 10:44 AM, Bastien ROUCARIES wrote:
>
> Bastien, can you please convince your mailer to preserve threading?
(sorry was on a long day train run and could only use the crappy android client)
> > For cygwin and windows plateform s
On 12/23/2010 06:13 AM, Jim Meyering wrote:
> Starting a daemon...
> Yes, that sounds challenging.
We'd have to start a new daemon for each directory, right?
So we'd need a hash table mapping directory FDs to info about
each daemon.
There's also the issue of signal safety, which we'd need to
thin
Le jeudi 23 décembre 2010 19:56:38, Paul Eggert a écrit :
> On 12/23/2010 06:13 AM, Jim Meyering wrote:
> inclined to think that going with subprocesses would be more
> trouble than it's worth.
So be simple, for each openat fork and pass fd to parent process.
Bastien
On 12/22/2010 03:25 PM, Paul Eggert wrote:
> Thanks for the review and these are all good suggestions; I'll
> look into them.
Following up my own email -- I pushed this:
>From a80e645dd8bb8bc1bfdce5a2805cbfd37567 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 23 Dec 2010 23:32:55 -08
36 matches
Mail list logo
