Are these critical test failures in glibc?
Hi,
I'm compiling glibc (Chapter 6.9 ; lfs-svn), and I get these errors: Code:
root:/sources/test# grep Error glibc-check-log |
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:
Hope this helps. |
Quote:
|
1 Attachment(s)
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?
|
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. |
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 |
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. |
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 |
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. :) |
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! |
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 :)
|
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 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. |
All times are GMT -5. The time now is 05:14 PM. |