glibc 2.9 "make check" fails on rt/tst-cputimer with "timer sig[12] invoked to soon"

shachter · 02-13-2009, 04:07 AM

I wish to install a new libc.so and have compiled the latest
glibc (2.9.90) with the latest gcc (4.3.3) and the latest
binutils (2.19, compiled with gcc 4.3.3). Compilation
succeeded without errors, although not before I did some non-
obvious things (e.g., I had to put '-march=i686' into my
CFLAGS to avoid getting undefined symbol errors from the
linker). 'Make check' also produced errors, a number of which
I averted by doing non-obvious things (e.g., I had to copy
iconvdata/gconv-modules and libio/tst-*.input from the source
directory to the build directory, and I had to export into the
environment TIMEOUTFACTOR=2; the glibc documentation gave me
no clue that I had to do any of those things). Now I am
running into an error with rt/tst-cputimer that I do not know
how to avert. I have run 'make check' 3 times; here are the
3 results. From rt/tst-cputimer1.out:

clock_gettime returned timespec = { 0, 8000000 }
clock_getres returned timespec = { 0, 1 }
*** timer sig1 invoked too soon: 2.908000000 instead of expected 3.408000000
*** timer sig2 invoked too soon: 2.908000000 instead of expected 3.908000000

And from rt/tst-cputimer2.out:

clock_gettime returned timespec = { 0, 0 }
clock_getres returned timespec = { 0, 1 }
*** timer sig1 invoked too soon: 2.900000000 instead of expected 3.400000000
*** timer sig2 invoked too soon: 2.900000000 instead of expected 3.900000000

Before running the 3rd 'make check', I increased TIMEOUTFACTOR
(to 3). It made no difference. From rt/tst-cputimer3.out:

clock_gettime returned timespec = { 0, 0 }
clock_getres returned timespec = { 0, 1 }
*** timer sig1 invoked too soon: 2.900000000 instead of expected 3.400000000
*** timer sig2 invoked too soon: 2.900000000 instead of expected 3.900000000

I don't want to install the new libc.so until I can get all the
tests to succeed, or, failing that, until I understand the
significance of the error, and can intelligently dismiss it.
What shall I do? Thank you in advance for your replies.

Jay F. Shachter
6424 North Whipple Street
Chicago IL 60645-4111
(1-773) 7613784
jay@m5.chicago.il.us
http://m5.chicago.il.us

knudfl · 02-13-2009, 04:33 PM

Which Linux are you using ? Suse 10 ?

I'd guess, you have build the gcc-4.3.3 also ?
The gcc people recommends the LFS method to build gcc
http://www.linuxfromscratch.org/lfs/view/6.4/
........ Compiling gcc against itself numerous times.
And in between recompile binutils and glibc again and
again with the new gcc, ending up with a toolchain,
where the individual tools talk well together.
... 'gcc' must be absolute perfect to compile 'glibc'.

Glibc 2.9 has been "done" ( a few times ? ), please have
a look into the patching found in the "src.rpm's" to see
how Suse 11.1 and Fedora 10 did this.

Suse 11.1 : binutils-2.19, gcc-4.3.3, glibc-2.9

Suse 11.1 source
http://download.opensuse.org/source/.../oss/suse/src/
............

Fedora 10 : binutils-2.18.50, gcc-4.3.2, glibc-2.9

Fedora 10 source
http://download.fedora.redhat.com/pu.../source/SRPMS/
.....
.....
Be aware, that your kernel ( and all applications )
depends on the current 'glibc'.
( I would make some extra backup, before the alien
glibc takes over. )
.....

knudfl · 02-14-2009, 01:24 PM

More information

http://www.gnu.org/software/libc/resources.html

Quote:

Building glibc is quite tricky and has a number of pitfalls, not the least
of which include :

* Never install over a live system. The connection between the individual
parts of the glibc shared libraries is special. The libc.so shared library
uses private interfaces in ld.so and vice versa. On a live system with
dynamically linked applications if a new libc.so replaces an old one with a
different internal ABI your system will be broken. libpthread.so, libm.so, and
librt.so have similar problems. At a minimum, install into a separate chroot
environment.
* There is a high possibility you will end up creating a different public
ABI. If you were to begin distributing binaries they would at a minimum not
work, and at best create a lot of confusion.

If you find yourself needing to build a customised version of glibc, you are
best to use the framework offered by your distribution (i.e. the rpm or deb
package build facilities).

....