Follow-up Comment #2, bug #17346 (project hurd):
This better?
vm_size_t memsize = boot_info.mem_upper;
if ((memsize >= 0x40))
memsize = (0x40-1);
phys_last_addr = 0x10 + (memsize * 0x400);
___
Reply to thi
Follow-up Comment #4, bug #17647 (project hurd):
And indeed: reverting the following makes the `libc.so' again work with GCC
4.1. Probably reverting the similar ones will be needed for non-shared
stuff, which I didn't test so far.
| #v+
| [...]
| void
| -_dl_init_first (int argc, ...)
| +_dl_in
Follow-up Comment #3, bug #17647 (project hurd):
| #v+
| $ gcc-4.0 test.c && ./a.out
| main:fa = 3216472808 fa[1] = 3084724428 ra = 3084724428
| func:fa[0] = 3216472808 fa[1] = 134513645 ra = 134513645
| #v-
|
| This is what I would expect. However:
|
| #v+
| main:fa = 3220364948 fa[1] = 322036
Update of bug #17647 (project hurd):
Status:None => In Progress
___
Follow-up Comment #2:
I had a look today. But now I think I need Roland's or someone else's help.
The problem is --- s
It should be using /dev/fd. As Chet said, figure out if the configure run
when building bash decided it wasn't there for some reason.
Also, test that /dev/fd is working right on the Hurd, e.g.:
$ exec 5> foobar
$ ls -li /dev/fd/5 foobar
$ exec 5>&-
This won't pretend to be a symlink like Linu
Thomas Schwinge wrote:
> Hello!
>
> There seems to be a problem with bash's usage of named pipes on GNU/Hurd
> systems.
Bash uses named pipes for process substitution only if /dev/fd (or the
Linux variant, /proc/self/fd) is not available. I'd check config.h to
see which is being used (look for H
Hello!
There seems to be a problem with bash's usage of named pipes on GNU/Hurd
systems.
#v+
[EMAIL PROTECTED]:~ $ diff -u <(echo a) <(echo b)
--- /proc/self/fd/632006-11-19 15:32:53.622504951 +0100
+++ /proc/self/fd/622006-11-19 15:32:53.614508451 +0100
@@ -1 +1 @@
-a
+b
[EMAIL PROTECTED
