[SOLVED] Are these critical test failures in glibc?

corbis_demon · 10-11-2010, 03:26 AM

Hi,
I'm compiling glibc (Chapter 6.9 ; lfs-svn), and I get these errors:

Code:

root:/sources/test# grep Error glibc-check-log
make[2]: [/tmp/glibc-2.12.1/glibc-build/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock6.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock7.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock9.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock11.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock12.out] Error 11
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock14.out] Error 1
make[1]: *** [nptl/tests] Error 2
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/rt/tst-cpuclock2.out] Error 1
make[1]: *** [rt/tests] Error 2
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/elf/tst-xmmymm.out] Error 1
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2

Some of these errors are pretty much expected, but others like the "/elf/tst-xmmymm.out" error are ones I've never encountered before. I searched for 'em online and found that it might be a critical failure (don't know for sure, though). Also, I've never had so many test case failures in the nptl clock tests. Do I have to rebuild? I've a Slackware64 machine as host.

druuna · 10-11-2010, 09:54 AM

Hi,

A few of the errors you posted are mentioned in the book and can be ignored, as you already stated.

The following need to be checked in the log file to see if they are time-out related (also mentioned in the book). If so you can ignore them, if not then something went wrong in this or one of the previous chapters and that needs to be fixed first.

List to check:

Quote:

make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock6.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock7.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock9.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock11.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock12.out] Error 11
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/nptl/tst-rwlock14.out] Error 1
make[2]: *** [/tmp/glibc-2.12.1/glibc-build/elf/tst-xmmymm.out] Error 1

BTW: Once you start with chapter 6 the original host isn't used, you are then using the temporary environment you build in chapter 5.

Hope this helps.

corbis_demon · 10-11-2010, 11:39 PM

Quote:

Originally Posted by druuna

BTW: Once you start with chapter 6 the original host isn't used, you are then using the temporary environment you build in chapter 5.

Yeah, I'm sorry, I forgot. What I wanted to mention was that I'm on a 64bit machine, because I read somewhere that the "/elf/tst-xmmymm.out" test was specific to a 64bit build, in fact so are most of the aforementioned nptl tests failures. Of course, I may be wrong.

corbis_demon · 10-12-2010, 12:53 AM

I've attached the relevant sections from the glibc test log. I'm really confused here, coz I tried compiling glibc on my slack64 system as well, and got the same errors. So what should I do, rebuild, coz I think I might end up with the same problems again?

druuna · 10-12-2010, 02:19 AM

Hi,

The errors in the attached file cannot be ignored. As you probably noticed as well, they end with segmentation faults and are definitely not time-out related. What slightly worries me is that these errors also show up when you try this on your host (Slackware), although I do not know the details of this "experiment".

If I'm not mistaken you already build a LFS 6.6 with success (this thread). The only difference I see in 6.6 and 6.7 (svn) are the optimization flags (CFLAGS) that are used:

LFS 6.6: "CFLAGS += -march=i486 -mtune=native" > configparms
LFS 6.7: "CFLAGS += -march=i486 -mtune=native -O3 -pipe" > configparms

You could try using the 6.6 flags instead of the 6.7 flags and see what happens (and tell the LFS team about this if it works).

I don't think using the 6.7 SVN version versus the LFS 6.7 version could be the culprit. The glibc chapter is the same for both (you might want to check the chapters leading up to glibc).

Hope this helps.

corbis_demon · 10-12-2010, 07:27 AM

Thanks druuna for the reply, and some very astute observation. Yes, I have already built an LFS system, your link providing the appropriate reference. That was a 32 bit build, and this is on 64 bit. So I don't think the optimization parameters

Code:

case `uname -m` in
  i?86) echo "CFLAGS += -march=i486 -mtune=native -O3 -pipe" > configparms ;;
esac

would apply in the current case. And yes it's worrying coz I have managed to replicate the same errors on another machine running Arch x86_64. I used the exact same commands used by lfs to try and compile glibc on Arch and Slackware. So it seems I would probably get the same errors, even if I rebuild, coz my test machines run the same version of glibc, with almost identical configs. So is there no way out?

druuna · 10-12-2010, 07:41 AM

Hi,

I'm not sure if the optimization parameters do or don't apply. I would have a look what uname -m shows and see if these flags are actually set when building a 32/64 bit LFS version.

Before my previous reply (#5) I did an extensive search on the errors shown and could not find anything that was related. The LFS 6.7 errata doesn't say anything about this either. Maybe you could check the LFS mailing lists to see if this has come up.....

I start to believe that this isn't something you are to blame for (bad copy/paste, deviating from book etc). This because it also shows on another box running a different distro (and they are not based on one another).

Not much to go on, but I hope it helps.

corbis_demon · 10-12-2010, 10:17 AM

Thanks drunna, for the reply. Running "uname -m" on my system gives "x86_64". As the LFS book points out, on a 32-bit system, glibc won't build without the above mentioned CFLAGS. I have tried compiling without it, and configuration fails. Using those CFLAGS on a 64-bit system will give you this eror:

Code:

<stdin>:1:0: error: CPU you selected does not support x86-64 instruction set
make[2]: *** [/root/glibc-build/ucontext_i.h] Error 1
make[2]: Leaving directory `/root/glibc-2.12.1/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/root/glibc-2.12.1'
make: *** [all] Error 2

I don't think "-march=x86_64" is a valid flag, so no luck there. I tried a lot other things, like changing the CFLAGS to "-O3 -fPIC" (as Slackware does), and that added another heap of errors. So no matter what I try, I seem to end up with these specific errors. I searched on-line and it was hinted on some glibc mailing lists that a kernel compiled with certain versions of gcc could bring out these errors. I also read in some lfs-support lists that it might do no harm to ignore these errors, as people have done it and haven't encountered any problem later. So I'll try and forge ahead, and hope I don't stumble badly. Thanks druuna for all your inputs.

corbis_demon · 10-18-2010, 10:44 AM

Hi all,
Sorry for digging this out, but I have successfully built an LFS/BLFS system on a 64bit box without any problems, despite having encountered the aforementioned errors. The only deviation from LFS instructions is I'm using a patched Linux-libre kernel. Also, using reiser4 as FS. Haven't had any hiccups yet, and keep hoping for the best.

druuna · 10-18-2010, 10:51 AM

Hi,

Great to see that you got it all working. And it is always nice to know that certain packages can be replaced by others that are more to the users liking (I still have to look into using the Linux-libre kernel you mentioned here and in another thread).

Have fun with your [B]LFS system!

corbis_demon · 10-18-2010, 11:27 AM

Thanks druuna. Since this is not a production build, I have experimented further. I have a GeForce GTX 480 card, and I'm using the Nouveau/Gallium3D libraries. Although performance is some way below par, compared to the proprietary drivers, it works nonetheless, and haven't had any crashes as yet. Have also built LibreOffice from source, and that's worked out quite alright. Now running the the DB test suite. Hope that build without errors

corbis_demon · 10-19-2010, 03:40 AM

Okay, an update on the "tst-rwlock" errors. This thread has some pertinent discussions about 'em. It seems they can be ignored. Also, in my case, another possible culprit could be the <linux-2.6.35/usr/include/linux/freezer.h> include in the -libre kernel. I got this error when installing the sanitized kernel headers:

Code:

/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:48: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:50: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:51: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:52: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:63: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:64: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:67: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:127: userspace cannot call function or variable defined in the kernel
/mnt/lfs/sources/test/linux-2.6.35/usr/include/linux/freezer.h:138: userspace cannot call function or variable defined in the kernel

Again, I may be wrong, but it could be related.

EDIT: This include doesn't seem to exist in the mainline kernel anymore, well, at least not at the above mentioned location. Maybe it's because I use a patched -libre kernel.