Hi,
Regarding glibc checking for the presence of file_exec_file_name in configure,
Thomas said he's happy if we just let the build fail if the RPC is not present.
Should we check for it or is that fine? If it's fine, I believe these patches
are ready to be pushed. If we need to check for it, I
Hi,
On Mon, Jul 26, 2010 at 07:28:42PM +0200, Emilio Pozuelo Monfort wrote:
New iteration. All mentioned issues have been fixed, except for the glibc
check
for the file_exec_file_name RPC, which I don't know how to do if not using
HURD_INTERFACE_VERSION. Any suggestions are welcome.
I have
Hi,
I have reviewed the patches and apart from formatting there were only
a couple of issues. Next iteration is hopefully the last.
On Thu, May 27, 2010 at 06:22:26PM +0200, Emilio Pozuelo Monfort wrote:
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
It would also be good if you always
Hi,
On Mon, May 31, 2010 at 06:27:29PM +0200, Carl Fredrik Hammar wrote:
Regarding version.h, I've bumped HURD_INTERFACE_VERSION in 0001 for
exec_exec_file_name, but should it be bumped in 0002 too?
This sounds good to me but if someone else objects you should change it.
antrik
Hi,
On Wed, May 26, 2010 at 04:45:12PM +0200, Carl Fredrik Hammar wrote:
On 26/05/10 09:32, olafbuddenha...@gmx.net wrote:
IIRC my major concern with this approach was that this way, the
original task has to guess what file name will be valid in the new
task's context... I don't
Hi,
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
Some of the changes that need to be made have already been discussed on
IRC: you should use string_t instead of data_t, empty string instead of
NULL for RPCs, and update copyright years,
All fixed.
The first three patches are pretty useless
On Tue, May 25, 2010 at 11:30:07PM +0200, Samuel Thibault wrote:
Emilio Pozuelo Monfort, le Tue 25 May 2010 23:03:43 +0200, a écrit :
Oh, I haven't noticed this file before. :-)
It's the list of symbols libc.so should export. Since _hurd_exec is a public
API, I guessed _file_name
On Wed, May 26, 2010 at 01:39:24AM +0200, Emilio Pozuelo Monfort wrote:
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
@@ -278,7 +280,9 @@ check_hashbang (struct execdata *e,
else
name = argv;
-if (strchr (name, '/') != NULL)
+if (filename)
+
Hi,
On Tue, May 25, 2010 at 11:03:43PM +0200, Emilio Pozuelo Monfort wrote:
The first three patches are pretty useless on their own, they all affect
the same program, and most changes are pretty mechanical, so I think
you might as well merge them.
OK. I thought about going step by step
Hi,
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
Basically the problem is that in some cases the exec server can't find
the file name of the file being executed (when it's a script), and
then makes a hack passing /dev/fd/N to the interpreter.
I tried to fix it
Hi,
On Tue, May 25, 2010 at 09:10:57PM +0200, Carl Fredrik Hammar wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
The first three patches are pretty useless on their own, they all
affect the same program, and most changes are pretty mechanical, so I
think you
Hi,
On 26/05/10 09:32, olafbuddenha...@gmx.net wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
Basically the problem is that in some cases the exec server can't find
the file name of the file being executed (when it's a script), and
then makes a hack passing
Emilio Pozuelo Monfort, le Wed 26 May 2010 12:29:06 +0200, a écrit :
There's a little bootstrapping problem here: you can't apply the four
Hurd patches directly and build the whole Hurd, because lib*fs will be
using exec_exec_file_name, but the dynamic linker can't find it, since
On Wed, May 26, 2010 at 12:29:06PM +0200, Emilio Pozuelo Monfort wrote:
On 26/05/10 09:32, olafbuddenha...@gmx.net wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
Basically the problem is that in some cases the exec server can't find
the file name of the
On Wed, May 26, 2010 at 09:42:05AM +0200, olafbuddenha...@gmx.net wrote:
I've commented on every hunk to make sure I looked through it all,
which makes it a bit long but hopefully easy to follow (complain if it
isn't).
Well, it certainly does make it pretty redundant...
I prioritized
Hi,
On Tue, May 25, 2010 at 09:10:57PM +0200, Carl Fredrik Hammar wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/exec/hashexec.c b/exec/hashexec.c
index 2aa3844..7a7b329 100644
--- a/exec/hashexec.c
+++ b/exec/hashexec.c
@@ -35,6 +35,7 @@
Hi,
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
These are a series of patches to fix https://savannah.gnu.org/bugs/?28934
Basically the problem is that in some cases the exec server can't find the
file
name of the file being executed (when it's a script), and
Hi Carl,
Thanks for the thorough review!
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
Some of the changes that need to be made have already been discussed on
IRC: you should use string_t instead of data_t, empty string instead of
NULL for RPCs, and update copyright years,
OK
The first
Emilio Pozuelo Monfort, le Tue 25 May 2010 23:03:43 +0200, a écrit :
Oh, I haven't noticed this file before. :-)
It's the list of symbols libc.so should export. Since _hurd_exec is a public
API, I guessed _file_name should be too. But if we don't want it to be
public, I
can probably put
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
@@ -278,7 +280,9 @@ check_hashbang (struct execdata *e,
else
name = argv;
- if (strchr (name, '/') != NULL)
+ if (filename)
+error = lookup (name = filename, 0, name_file);
+ else
Hi,
These are a series of patches to fix https://savannah.gnu.org/bugs/?28934
Basically the problem is that in some cases the exec server can't find the file
name of the file being executed (when it's a script), and then makes a hack
passing /dev/fd/N to the interpreter.
I tried to fix it with
21 matches
Mail list logo
