You are not logged in.
I'm trying to compile glibc in debug mode, so I added two lines right after build()
build() {
export CFLAGS="$CFLAGS -g -O1"
export CXXFLAGS="$CXXFLAGS -g -O1"
(stock compilation doesn't work either)
then after some time getting this
GCONV_PATH=/tmp/glibc/src/glibc-build/iconvdata LC_ALL=C /tmp/glibc/src/glibc-build/elf/ld-linux-x86-64.so.2 --library-path /tmp/glibc/src/glibc-build:/tmp/glibc/src/glibc-build/math:/tmp/glibc/src/glibc-build/elf:/tmp/glibc/src/glibc-build/dlfcn:/tmp/glibc/src/glibc-build/nss:/tmp/glibc/src/glibc-build/nis:/tmp/glibc/src/glibc-build/rt:/tmp/glibc/src/glibc-build/resolv:/tmp/glibc/src/glibc-build/crypt:/tmp/glibc/src/glibc-build/nptl /tmp/glibc/src/glibc-build/rt/tst-cpuclock2 > /tmp/glibc/src/glibc-build/rt/tst-cpuclock2.out
Timed out: killed the child process
make[2]: *** [/tmp/glibc/src/glibc-build/rt/tst-cpuclock1.out] Błąd 1
make[2]: *** Oczekiwanie na niezakończone zadania....
Timed out: killed the child process
make[2]: *** [/tmp/glibc/src/glibc-build/rt/tst-cpuclock2.out] Błąd 1
rm /tmp/glibc/src/glibc-build/rt/librt.dynsym
make[2]: Opuszczenie katalogu `/tmp/glibc/src/glibc-2.16.0/rt'
make[1]: *** [rt/tests] Błąd 2
make[1]: Opuszczenie katalogu `/tmp/glibc/src/glibc-2.16.0'
make: *** [check] Błąd 2
no errors except Timed out: killed the child process. I've never ever had such strange issue.
I need glibc with symbols to post detailed information about bug I've founded ... such an ironic problem ... ;]
Here is part of my makepkg.conf
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-unknown-linux-gnu"
#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CFLAGS="-march=core2 -msse4.1 -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 " #-std=c11" # -flto -fwhole-program"
CXXFLAGS="-march=core2 -msse4.1 -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 " #-std=c++11" # -flto -fwhole-program"
#CFLAGS="-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
#CXXFLAGS="-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" #-flto=2 " #-fwhole-program " #-fuse-linker-plugin "
#LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j2"
Last edited by travnick (2013-01-30 00:00:58)
Offline
That is the test-suite failing - on a not very important bit that is often expected to fail.
Anyway... I though glibc required -O2 to build, but perhaps -O1 is enough:
http://sourceware.org/glibc/wiki/FAQ#Wh … _GNU_CC.3F
Edit: you think the bug is in glibc?
Offline
I'm trying to trace a bug in openssh which leads to glibc.
I've tried to build glibc from repo without ANY modifications in PKBUILD, but it failed too ...
Last edited by travnick (2012-12-17 16:15:54)
Offline
Hi,
I am having the same problem. Basically most (all?) glibc unit tests uses the same tst-skeleton.c and specific test are executed in a child process. The test function will timeout if the child do not exit after a default timeout of 2 seconds.
This is overriden for some tests which are known to take longer. The one that is failing for you has a timeout defined of 5 seconds. Perhaps you are checking your newly compiled lib on a slow machine...
A possible workaround might be to use glibc test framework ability to increase timeout values by a multiplicative factor.
The environment variable TIMEOUTFACTOR does just that.
Possibly:
$ export TIMEOUTFACTOR=2
$ makepkg
or
$ TIMEOUTFACTOR=2 makepkg
could make your glibc compilation successful.
Please report back if it helps!
Olivier
Offline
Here is a little update:
I have played a little bit with glibc TIMEOUTFACTOR and even with 30 secs or 1 minute, I still have the timeout.
I have checked a littlebit the test unit source code and it should not be taking that long. Essenstially, the test forks a child that does bogus computation and the parent process is supposed to call clock_nanosleep() with the child CPU clock.
The parent process never returns from clock_nanosleep() with a timeout value of 100ms!
Since glibc is essentially a thin wrapper for kernel system call, this might be a symptom of a kernel problem.
I'm using linux-ck from Arch unofficial repo-ck. I'll rechecking my glibc compilation with standard Arch Kernel to see if I'm getting a different result soon.
In the meantime, just out of curiosity, which kernel are you using?
Offline
unit test is fine with Arch default kernel.
the function glibc clock_nanosleep() fails only with linux-ck.
Will report the problem to ck and try to fix it if I can.
Offline
I'm using linux-pf one
My machine isn't the 1000x i7 cluster but not a wooden PC either:
core 2 duo T8400, 8 gb ram
so probably linux-pf is also affected.
Offline
I'll repeat this...
That is the test-suite failing - on a not very important bit that is often expected to fail.
These tests are know to fail commonly... it is not an issue.
Offline
Allan,
Do you have a link supporting your claim?
As far as I am concerned, I agree that these tests may commonly fail without dire consequences because they are testing an obscure system call.
I am a system developer with over 15 years of experiences and I have never seen any application code using clock_nanosleep() (let alone mention calling this function with the cpu clock id of another process!).
*but* the unit test is correct by reporting a problem with the patched kernels as they do not implement correctly this functionality.
Offline
I'm not sure it is fully documented anyway - just a well know test with issues. e.g. see the LFS testsuite guidlines:
http://lfsbook.linuxfromscratch.org/lfs … glibc.html
Offline
unit test is fine with Arch default kernel.
the function glibc clock_nanosleep() fails only with linux-ck.
Will report the problem to ck and try to fix it if I can.
Thanks for following up on this. For those who haven't seen it yet, here is an excerpt from CK's blog regarding this:
Unfortunately it took me quite a while to find since I had to dig deep into figuring out how the whole system of timers works on a low level in the kernel before finally stumbling across one tiny piece of accounting/reporting that was missing on BFS. It's funny that a bug that directly affected almost no one should be so hard to track down. In the meantime it allowed me to tweak a number of bits of internal accounting so hopefully that should have improved as well.
Plz mark your thread as solved if it is so.
Last edited by graysky (2013-01-29 19:57:59)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I'm using linux-pf one. But tested Glibc on stock arch kernel and it succeed to compile so linux-pf is affected too.
Offline
I'm using linux-pf one. But tested Glibc on stock arch kernel and it succeed to compile so linux-pf is affected too.
Of course it is... the bfs is part of the pf patchset. You'll need to wait for post-factum to update his patchset.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I passed over "BFS" while reading... I'm tired ;]
You'll need to wait for post-factum to update his patchset.
He's got a mial!
Offline
I'd like to be able to fix the issue but I cannot, so we should mail Con instead.
uname == latest pf-kernel
Offline
@pf - you're saying that even BFS v0.427 does not fix the issue for you?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
In fact, I haven't compiled glibc, so I haven't faced that issue. Could you try pf-kernel from git tree (I've updated BFS there) and tell us if the problem persists?
uname == latest pf-kernel
Offline
Sorry, but I'm really busy for a while. In three weeks time I'll try to do some testing.
I don't know if this issue is related with the other one that I found, but probably it is: https://bbs.archlinux.org/viewtopic.php … 2#p1229432
Offline