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:

• 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
  

• Also in other places: configure fragments that have *linux* cases might/should often contain those for us (and GNU/k*BSD) as well.

• 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, but what are these error messages?

$ 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' ...
[...]

Depends on libdbd-sqlite3-perl.

Does build, but has test-suite problems (only where libdbd-sqlite3-perl is involved, it seems):

[...]
DBD::SQLite::db table_info failed: database is locked(5) at dbdimp.c line 271 at /media/data/home/tschwinge/tmp/git-core/git-core-1.5.6.5/t/../
git-cvsserver line 2783, <STDIN> line 17.
Can't call method "fetchall_hashref" on an undefined value at /media/data/home/tschwinge/tmp/git-core/git-core-1.5.6.5/t/../git-cvsserver line 
2783, <STDIN> line 17.
[...]

Stopping the test-stuite (C-c), doing a touch build-arch-stamp, followed by re-running dpkg-buildpackage with -nc will yield an installable deb package.

Does build, but has test-suite problems:

t/02cr_table............ok 1/4DBD::SQLite::db do failed: database is locked(5) at dbdimp.c line 271 at t/02cr_table.t line 10.
DBD::SQLite::db prepare failed: database is locked(5) at dbdimp.c line 271 at t/02cr_table.t line 11.
Can't call method "execute" on an undefined value at t/02cr_table.t line 12.
t/02cr_table............dubious
        Test returned status 118 (wstat 30208, 0x7600)
DIED. FAILED tests 2-4
        Failed 3/4 tests, 25.00% okay
t/03insert..............ok 1/11DBD::SQLite::db do failed: database is locked(5) at dbdimp.c line 271 at t/03insert.t line 6.
# Failed test 2 in t/03insert.t at line 6
[...]

Stopping the test-stuite (C-c), doing a touch build-stamp, followed by re-running dpkg-buildpackage with -nc will yield an installable deb package.