last time (3 days ago) i compiled gcc 4.6.2 on this machine (intel i7-2600 with 8gb ram) the compile run 2 minutes, the tests 16min.
as far as i can see, i used the 7.0 release almost to the letter... (i upgraded the kernel and kernel-headers to 3.1.4) using this 7.0 system as base, i wanted to restart with current dev. compiling gcc 4.6.2 still needs 2 minutes, but the tests run for incredible 11h37mins. i had 429 failures in the libmudflab part (cat LOG | grep libmudflap.c|grep FAIL|wc -l) almost all of this failures are followed by WARNING: program timed out cat LOG|grep "timed out"|grep WARN|wc -l : 250 the statistics say 998 expected passes and 429 unexpected failures (same number as my grep/wc) what is exactly the same numbers as my last compile. the difference is the current run adds the 'program timed out' warnings and needs 11:26h more time to get the same result ;( a quick look in the log shows no other strange entries. my scripts are stil running, without any further problems. i just was puzzled when i came home, as i expected to have either the job done or a failure in a package. but gcc test running all day long i've never seen before! all binaries built with the current job (current dev) are slightly smaller then the files from the last run (7.0) as i couldn't find anything with google, i'm asking for help here. anybody any idea what i might have screwed??? the build already finished the LFS stuff and started with the packages i use from BLFS. i'll report tomorrow wether the system is stable or not. i guess it will be stable. i just would like to know WHY the libmudflap test are running for ever, with timeout on every single test. thanks for any help tobias -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
