Re: gcc test failures
Alex Bosworth wrote: Here's the synopsis: Been trying to compile LFS (from the latest svn version) on my laptop, I have tried four times so far (please note I'm making use of JHLAFS). During all the four builds, gcc tests don't seem to be satisfactory as the number of unexpected failures is too high and the number of expected passes is too low. I have tried changing the CFLAGS and tried to be conservative but, the result seems to be the same. The fourth time I chose to run tests both for the tools and the final system. As I can see tests for all other packages are successful (All # tests were successful) except for gcc ! The CFLAGS I used for the fourth build are -O3 -pipe -msse -msse2 -mmmx -march=native -mtune=native. The processor is an Intel Penitum4 Mobile. The only deviations from the SVN book are m4 (using 1.4.16), mpc (using 0.9), less (using 446). Here's the grep -A7 Summ output: === g++ Summary === # of expected passes6 # of unexpected failures3543 I agree that this number of failures is way too high. Since you are using jhalfs, the problem is not a typo. I would suspect a hardware problem of some kind. Do you have enough free memory or diskspace? Can you duplicate the problme on another system? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sat, 12 Mar 2011 19:11:37 -0600
Dan McGhee beesnee...@att.net wrote:
This is what I was hoping to hear--that the logic is sound,but that
there might be a problem in the construct. I've shied away from ( )
and {} in $ xxx statements because I'm really shaky on what they
mean. I've also never seen the ' ' [ ] ' ' construct. I use the
Advanced Bash Scripting Guide as my reference. Thank you for your
feedback. I'll play with this.
Those (the '' thing) were quotes I used for inclusion in text.
Instead of writing
[ blah ]
I just wrote ''[ blah ]'' inline. Remove the quotes (luckily
they enclose empty strings so even if you don't remove them, they
should not change the meaning of the expression).
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sunday 13 March 2011 14:12:20 Dan McGhee wrote:
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Generally, single- and double-quotes allow for spaces in strings and for null
(or empty) strings. Double-quotes allow $xxx shell variables to be expanded;
single-quotes prevent expansion. Learning to automatically quote strings leads
to long-term hair retention. I usually use quotes because they result in
clearer syntax than one gets when using \ escaping.
var=two words
if [ $var == two words ]; then ... fi
and
var=two\ words
if [ $var == two\ words ]; then ... fi
are equivalent; the quoted form is clearer and is often the only way to make
it work.
Also, I must amend my msg re: the explicit semi-colon I included following the
last command when using the ' { commands; } syntax. I was mistaken. They
aren't necessary when the commands are on separate lines, as in:
... {
command 1
command 2
}
but it won't hurt to have them there. Semi-colons are only needed to terminate
commands when they are on one line, as in:
... { command 2; command 2; }
It is standard, consistent shell syntax.
I thought I tested it both ways before clicking send; clearly I didn't.
N
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: gcc test failures
On Sunday 13 March 2011 15:50:43 Alex Bosworth wrote: I don't think this is a hardware problem as none of the other packages fail their tests and I don't encounter any crashes or errors during normal use. Don't be too quick to write off hardware problems. Building gcc is well known for uncovering latent hardware faults, just as it did when I first built it in the mid '90s and kept hitting the 'signal 11' error. When I build my firewall on my quad-core desktop (using 'make -j 4' for most packages), only two packages get the CPU up to 60C and hold it there for 1-3 minutes: gcc and the kernel. The kernel build is mostly 'busy work'. But the gcc build exercises a lot of the CPU and RAM; if there's a heat weakness or other hardware instability, building gcc may well uncover it. To be sure, I'm not saying it *is* a hardware problem. But if it only happens to GCC, it could be hardware-related. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 06:00 PM, Dan McGhee wrote: One thing I want it to do is recover from a failed 'make' or 'install' without have to run the whole script again. This feature *used to* work. It now doesn't. If everything is OK, the script runs from the beginning to the successful end of a build. But if there is a glitch, the recovery doesn't happen. I'm replying to my own original post. Needed to have some stuff that the others snipped to show the error of my ways. The script was doing exactly what I told it to do. There were no problems with variables, syntax or exit status. What I didn't put in my original post, and this is my personal logic error, is that when I exited the script after make, simulating a failed install, it started at make again and not install. Please look at the following sequence. # This one recovers from failed make. if [ -e $logdir/make-`echo $package`.err ] \ [ ! -e $logdir/install-`echo $package`.err ]; then # This one recovers from a failed install if [ -e $logdir/make-`echo $package`.log ] \ [ ! -e $HOME/$package-files.list ]; then # This one does everything through configure, make, make install if [ ! -e $logdir ]; then The order is failed make, failed install and fresh build. If the install fails after make, the conditions exist to make,and the script will start there. So the order of the first two tests needed to be reversed. I did that and everything works the way I want it to. Thanks, Aleksandar and Neal, for your inputs. My syntax is now more elegant in addition to working. I learned a trick from the Advanced Bash Scripting Guide that proved to me that everything was as it should be except what I wanted the script to do. I had inspected and made sure that all the files and directories existed and had the right names. They did. But that didn't mean that the tests were parsing everything correctly, so I wanted to do something to test the test. I stumbled on this which is exactly what I needed: if [ -e $file ]; then echo $file exists else echo $file does not exist fi Inserting two loops like this to check my tests is what lead me to realize that the test order was not correct. Once again, thanks for the responses. I learned quite a bit. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: gcc test failures
I don't think this is a hardware problem as none of the other packages fail their tests and I don't encounter any crashes or errors during normal use. As far the disk space and memory are concerned I do have about 768MB of RAM with 1GB swap with several GBs of free disk space. I have compiled LFS/BLFS a few times before this and I never had any problems then. As I'm using JHALFS, it includes gcc and a few other packages from custom optimizations. So it has nothing to do with the custom optimizations at least not directly. I did not test memory requirement in a while, but as far as I remember, gcc required at least 2.5 GB of memory. That is RAM + swap. Either use a swap file or set your swap to 3GB and try again. Good luck, Dominic. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: gcc test failures
On Sun, Mar 13, 2011 at 12:50:43PM -0700, Alex Bosworth wrote: I don't think this is a hardware problem as none of the other packages fail their tests and I don't encounter any crashes or errors during normal use. As far the disk space and memory are concerned I do have about 768MB of RAM with 1GB swap with several GBs of free disk space. I have compiled LFS/BLFS a few times before this and I never had any problems then. As I'm using JHALFS, it includes gcc and a few other packages from custom optimizations. So it has nothing to do with the custom optimizations at least not directly. I'm always dubious about adding -O3 when a package defaults to -O2. I know that Greg used to use it for glibc in DIY, so it's probably ok in that, but for gcc I would immediately suspect it if you get problems. Dunno if jhalfs supports changing the flags for individual packages, I don't use it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce Oops ! My bad !! I meant to say jhalfs excludes gcc and a few other from custom optimizations. I have checked to make sure and I don't see any of the flags I have set in the gcc build/test logs. I did not test memory requirement in a while, but as far as I remember, gcc required at least 2.5 GB of memory. That is RAM + swap. Either use a swap file or set your swap to 3GB and try again. Good luck, Dominic. Like I mentioned before, I compiled LFS/BLFS and gentoo on this machine and never have had any prblems. Only recently (about a a week ago), I upgraded the gentoo gcc build and it compiled just fine (I didn't have the test phase enabled though). The first time I build LFS, my laptop had only 562MB of RAM and gcc compiled/tested just fine !! Unless the memory requirements have changed for gcc 4.5.x I believe 768MB shouldn't be a problem. Don't be too quick to write off hardware problems. Building gcc is well known for uncovering latent hardware faults, just as it did when I first built it in the mid '90s and kept hitting the 'signal 11' error. When I build my firewall on my quad-core desktop (using 'make -j 4' for most packages), only two packages get the CPU up to 60C and hold it there for 1-3 minutes: gcc and the kernel. The kernel build is mostly 'busy work'. But the gcc build exercises a lot of the CPU and RAM; if there's a heat weakness or other hardware instability, building gcc may well uncover it. To be sure, I'm not saying it *is* a hardware problem. But if it only happens to GCC, it could be hardware-related.. That MIGHT be it. I just noticed that the heatsink fan seems to be not functioning, only the CPU fan is working. That explains why my laptop has been running so quietly since the last few weeks (I used to wonder why, now I know !!). I were making use of -j2 make option, I wonder if would make a difference if I set it to -j1 and lower the priority for make (perhaps set it to +20 ?) and see if that helps to keep the heat low !? I won't be able to test it out until a while, as I will be out of town. I will be taking my laptop with me, but not sure if I would get a chance to use it. Thanks for all the help. I guess I will have to come back and report, once I've had time to give it another try. Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: gcc test failures
On Sunday 13 March 2011 23:48:52 Alex Bosworth wrote: I were making use of -j2 make option, I wonder if would make a difference if I set it to -j1 and lower the priority for make (perhaps set it to +20 ?) and see if that helps to keep the heat low !? '-j 1' will definitely make a difference, but setting the nice value won't (assuming you aren't running any unrelated cycle-munching programs). If that isn't enough, then reduce the maximum processor frequency via cpufreq-utils or via the /proc or /sys interface. Take a gander at: http://idebian.wordpress.com/2008/06/22/cpu-frequency-scaling-in-linux/ Try setting it to 'powersave' while compiling gcc and otherwise set it to ondemand. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
