<terpstra> do the buildds also crash?
<youpi> sometimes
<youpi> usually when a configure scripts tries to find out how large a
  command line can be
<youpi> (thus eating all memory)

Here is a replacement to use, until the real top works, which depends on procfs and some porting.

$ while :; do ps -e -v -s CPU --top=22 -r; sleep 5; done

bash 4.0 vs. typing C-c (SIGINT)

Will show -bash: echo: write error: (ipc/mig) wrong reply message ID unter certain conditions.

After having noticed that this error doesn't occur if starting bash with --norc, I isolated it to the following command in .bashrc:

case $TERM in
  xterm* | rxvt*)
    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';;
esac

... and indeed:

tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND"
xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"
tschwinge@flubber:~ $ ^C
-bash: echo: write error: (ipc/mig) wrong reply message ID
tschwinge@flubber:~ $ PROMPT_COMMAND=
tschwinge@flubber:~ $ ^C
tschwinge@flubber:~ $ 

bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ '
foo bash-4.0$ ^C

bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ '
foo bash-4.0$ ^C
bash: echo: write error: (ipc/mig) wrong reply message ID

bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ '
foo bash-4.0$ ^C
bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID

So, there's something different with stdout in / after the SIGINT handler.

Typing C-c (SIGINT) in a screen session (Debian package 4.0.3-14; -11 is fine):

• shell prompt: no reaction (nothing printed)
• sleep 10 running: ^C printed, but SIGINT is not sent.

Debian bug #522689#38.

Revisit this issue: Debian bug #97343 -- special handling of TIOCSCTTY depending on __GNU__.

#ifdef linux and friends are used in quite a number of places.

All diffs are GNU/Linux vs. GNU/Hurd.

 /*
  * If your system supports BSD4.4's seteuid() and setegid(), define
  * HAVE_SETEUID.
  */
-/* #undef HAVE_SETEUID */
+#define HAVE_SETEUID 1

TODO: check.

 /*
  * define HAVE_SVR4_PTYS if you have a /dev/ptmx character special
  * device and support the ptsname(), grantpt(), unlockpt() functions.
  */
-#define HAVE_SVR4_PTYS 1
+/* #undef HAVE_SVR4_PTYS */

 /*
  * define HAVE_GETPT if you have the getpt() function.
  */
 #define HAVE_GETPT 1

 /*
  * define HAVE_OPENPTY if your system has the openpty() call.
  */
-/* #undef HAVE_OPENPTY */
+#define HAVE_OPENPTY 1

 /* 
  * define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen
  * to unusual environments. E.g. For SunOs the defaults are "qpr" and 
  * "0123456789abcdef". For SunOs 4.1.2 
  * #define PTYRANGE0 "pqrstuvwxyzPQRST" 
  * is recommended by Dan Jacobson.
  */
-/* #undef PTYRANGE0 */
-/* #undef PTYRANGE1 */
+#define PTYRANGE0 "pq"
+#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv"

TODO: check: HAVE_SVR4_PTYS is due to configure.in doing test -c /dev/ptmx. But: even if we don't have that file, we still have ptsname, grantpt, unlockpt.

 gcc -c -I. -I.    -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c
+pty.c: In function 'OpenPTY':
+pty.c:323: warning: implicit declaration of function 'openpty'
+pty.c: At top level:
+pty.c:75: warning: 'PtyName' defined but not used
+pty.c:86: warning: 'PtyProto' defined but not used
+pty.c:87: warning: 'TtyProto' defined but not used

TODO: check.

--- linux/osdef.h       2009-10-06 18:43:53.000000000 +0200
+++ screen-4.0.3/osdef.h        2009-10-06 18:49:49.000000000 +0200
@@ -42,13 +42,19 @@
 #endif

 #ifdef SYSV
+extern char *strchr __P((char *, int));
+extern char *strrchr __P((char *, int));
+extern char *memset __P((char *, int, int));
+extern int   memcmp __P((char *, char *, int));
 #else
 #endif

 #ifndef USEBCOPY
 # ifdef USEMEMCPY
+extern void  memcpy __P((char *, char *, int));
 # else
 #  ifdef USEMEMMOVE
+extern void  memmove __P((char *, char *, int));
 #  else
 #  endif
 # endif

TODO: check.

m4 (1.4.13-1+hurd.2) unreleased; urgency=low

  * Drop stack overflow (checks/stackovf) check, test-c-stack and
    test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks.

 -- Samuel Thibault <samuel.thibault@ens-lyon.org>  Tue, 18 Aug 2009 20:54:30 +0000

<youpi> that was a quick fix  (as not having m4 makes autoconf uninstallable, which is quite a problem)
<youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated

GNU Emacs mostly does work, however there are a few issues.

• dired on a directory hangs. (Use C-g C-g to break the unresponsive operation.)

• Configuration in src/s/: gnu.h uses bsd-common.h. gnu-kfreebsd.h uses gnu-linux.h -- we probably should too.

  • gnu-linux.h makes a few things depend on /proc (also see HAVE_PROCFS) -- either resort to our own ways, or enhance our procfs accordingly.

    • sysdep.c

• Got a hang when compiling GNU Emacs 23, when it was compiling .el to .elc files. Looked like busy-looping inside glibc. This was not reproducible so far.

• Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in ext2fs on /media/data when resuming emacs23 build in ~/tmp/emacs/emacs23-*/ (dpkg-buildpackage -B -uc -nc 2>&1 | tee L). No modifications to emacs23-* so far, I think. Hangs always in the same place, it seems, and reproducible. Tarred to emacs23-23.1+1.tar.bz2 (beware: empty and zero-permission files: emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el, emacs23-23.1+1/.pc/autofiles.diff/src/config.in~). At hang-time: the rootfs is fine (syncfs -c -s / works; syncfs involving /media/data hangs). Plan: GDB on that ext2fs, and see what's hanging / locked.

syncfs is a tiny wrapper around the file syncfs RPC.

Its functionality should me merged into GNU coreutils' sync program, see GNU Savannah task #6614.

Neither the time executable from the GNU time package work completely correctly, nor does the GNU Bash built-in one.

tschwinge@flubber:~ $ \time sleep 2
0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 4
0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 6
0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ time sleep 2

real    0m2.093s
user    0m0.000s
sys     0m0.011s
tschwinge@flubber:~ $ time sleep 4

real    0m4.083s
user    0m0.000s
sys     0m0.010s
tschwinge@flubber:~ $ time sleep 6

real    0m6.164s
user    0m0.000s
sys     0m0.010s

GNU time's elapsed value is off by some factor.

$ \time factor 1111111111111111111
1111111111111111111: 1111111111111111111
0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
$ time factor 1111111111111111111
1111111111111111111: 1111111111111111111

real    0m11.424s
user    0m0.000s
sys     0m0.010s

As above; also here all the running time should be attriuted to user time. This is probably a open issue gnumach.

Just like GRUB (legacy), GRUB2 needs to be ported for being installable when attempted to be installed from GNU/Hurd systems:

$ sudo grub-probe --target=device /boot/grub
grub-probe: error: cannot find a device for /boot/grub.

Etc.

Even though it is customarily used for booting GNU/Hurd systems, GRUB, specifically GRUB legacy (which is still in wide-spread use, despite that rather depricative nickname), has never been ported to be installable when attempted to be installed from GNU/Hurd systems:

# grub-install \(hd0\)
df: Warning: cannot read table of mounted filesystems
df: Warning: cannot read table of mounted filesystems
Could not find device for /boot: Not found or not a block device.

There is a patch, grub-install.patch, to fix that.

grub-install, however, still fails while invoking grub:

# grub-install \(hd0\)
The file /boot/grub/stage1 not read correctly.

# grub
[...]
grub> dump (hd0,0)/boot/grub/stage1 /tmp/grub_stage1

Error 18: Selected cylinder exceeds maximum supported by BIOS

The successor, GRUB2, also needs to be ported.

socat needs porting. Some work has already been done in 2007, see http://www.dest-unreach.org/socat/contrib/socat-hurd.html or contact Thomas Schwinge.

On the otherwise-idle flubber:

$ git clone git://sources.redhat.com/git/glibc.git
Initialized empty Git repository in /media/data/home/tschwinge/tmp/glibc/glibc/.git/
remote: Generating pack...
remote: Done counting 380933 objects.
remote: Deltifying 380933 objects...
remote:  100% (380933/380933) done
remote: Total 380933 (delta 294166), reused 380686 (delta 294002)
Receiving objects: 100% (380933/380933), 70.31 MiB | 27 KiB/s, done.
Resolving deltas: 100% (294166/294166), done.
error: git-checkout-index: unable to create file iconvdata/ibm1122.c (Interrupted system call)
error: git-checkout-index: unable to create file localedata/charmaps/IBM862 (Interrupted system call)
Checking out files: 100% (10676/10676), done.
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   iconvdata/ibm1122.c
#       modified:   localedata/charmaps/IBM862
#
no changes added to commit (use "git add" and/or "git commit -a")
$ ls -l iconvdata/ibm1122.c localedata/charmaps/IBM862
-rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 iconvdata/ibm1122.c
-rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862

So these files are indeed of zero-length in the checked-out tree. Is this git's fault or something else's?

Fixing this situation is easy enough:

$ git checkout -- iconvdata/ibm1122.c localedata/charmaps/IBM862
$ git status
# On branch master
nothing to commit (working directory clean)

Modify the cross-compiling shell script to configure GCC for building GCC with C++ support when building its second (i.e., final) version.

Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the resulting binaries would also work), but linking fails with GCC SVN trunk:

$ $TARGET-g++ -Wall a.cc -lpthread
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2'
/home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2'
collect2: ld returned 1 exit status

Whether this defect report also applies to a natively-build GCC from SVN trunk has not yet been checked.

Thomas Schwinge suspects the problem to be a configuration issue of a GCC helper library, whose configuration setup has changed after GCC 4.3.

The need for -lpthread is another story. See the Debian glibc patches repository for details.

Single-threaded use appears to work:

$ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
  gcc -o a -fmudflap -x c - -lmudflap
$ ./a
*******
mudflap violation 1 (check/write): time=1227208721.922064 ptr=0x1023de0 size=4
pc=0x1037a33 location=`<stdin>:1:26 (main)'
      /usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
      ./a(main+0x7c) [0x80486c4]
      /usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
Nearby object 1: checked region begins 68B before and ends 65B before
mudflap object 0x80ca268: name=`argv[]'
bounds=[0x1023e24,0x1023e2b] size=8 area=static check=0r/0w liveness=0
alloc time=1227208721.922064 pc=0x10371d3
Nearby object 2: checked region begins 76B before and ends 73B before
mudflap object 0x80cb448: name=`environ[]'
bounds=[0x1023e2c,0x1023ed7] size=172 area=static check=0r/0w liveness=0
alloc time=1227208721.922064 pc=0x10371d3
number of nearby objects: 2
*******
mudflap violation 2 (check/read): time=1227208721.942109 ptr=0x1023dcc size=4
pc=0x1037a33 location=`<stdin>:1:35 (main)'
      /usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
      ./a(main+0xf3) [0x804873b]
      /usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
Nearby object 1: checked region begins 88B before and ends 85B before
mudflap object 0x80ca268: name=`argv[]'
Nearby object 2: checked region begins 96B before and ends 93B before
mudflap object 0x80cb448: name=`environ[]'
number of nearby objects: 2

Multi-threaded use doesn't:

$ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
  gcc -include pthread.h -o a -fmudflapth -x c - -lmudflapth -lpthread
$ ./a 
Killed
$ gdb a
[...]
Starting program: /media/data/home/tschwinge/a 

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x01180653 in getenv () from /lib/libc.so.0.3
(gdb) bt
#0  0x01180653 in getenv () from /lib/libc.so.0.3
#1  0x01177a02 in __dcigettext () from /lib/libc.so.0.3
#2  0x01176a57 in dcgettext () from /lib/libc.so.0.3
#3  0x011c03b5 in strerror_r () from /lib/libc.so.0.3
#4  0x01175b57 in __assert_perror_fail () from /lib/libc.so.0.3
#5  0x0111f1ad in cthread_fork (func=0x114f630 <_hurd_msgport_receive>, arg=0x0)
    at /build/buildd/hurd-20080607/build-tree/hurd/libpthread/pthread/cthreads-compat.c:41
#6  0x0115713e in _hurdsig_init () from /lib/libc.so.0.3
#7  0x01140852 in _hurd_proc_init@@GLIBC_2.2.6 () from /lib/libc.so.0.3
#8  0x01140e86 in _hurd_init () from /lib/libc.so.0.3
#9  0x011690ce in init1 () from /lib/libc.so.0.3
#10 0x00001e96 in _dl_start_user () from /lib/ld.so
#11 0x00000001 in ?? ()
#12 0x01024000 in ?? ()
#13 0x00000000 in ?? ()

Also libmudflap is pthread-only.

For GCC trunk:

Debian package has patches (for 4.3). Some have been forwarded upstream. (And have been ignored.) Thomas Schwinge is working on getting them integrated.

• [meta-bug] bootstrap bugs for *-gnu*

• build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

• -fstack-protector shouldn't use TLS in freestanding mode

• Tool chain configuration: GNU/* sharing stuff with GNU/Linux

Additionally:

• Configure fragments that have *linux* cases might/should often contain those for us (and GNU/k*BSD) as well.

  • libgcc/configure.ac might need to be aligned for us to the *linux* cases. As well as at the end of libgcc/config.host. Check.

    checking whether decimal floating point is supported... no
    checking whether fixed-point is supported... no
    

  • libgomp/configure.tgt

• libmudflap.

• C++.

The runit package doesn't work, even its test suite doesn't finish.

Thomas Schwinge once was having a look at that, but this very report is just from his memory, and his memory is dim... The problem might either be a time stamping issue (which might be fixed by now) or it might be the select call failing issue we're seeing from time to time. Or something else.

<azeem> seems pth still doesn't work
<bddebian> Doesn't build or doesn't work?
<azeem> both
<azeem> some configure test keep grinding the CPU, same for the test suite
<azeem> which apparently runs pth_init() and never returns

adduser does work as expected, the following warnings are spurious, they just appear when one doesn't have the nscd package. They do not appear on linux boxes because there posix_spawn doesn't report ENOENT for exec(). Posix indeed says that `if the error occurs after the calling process successfully returns, the child process shall exit with exit status 127'. The hurd however reports all errors, thus the warning.

$ sudo adduser foo
Adding user `foo' ...
Adding new group `foo' (1002) ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Adding new user `foo' (1002) with group `foo' ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Creating home directory `/home/foo' ...
Copying files from `/etc/skel' ...
[...]