Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Tue, 2012-01-10 at 10:11 -0600, Bruce Dubbs wrote: Simon Geard wrote: On Mon, 2012-01-09 at 08:57 -0700, jasonps...@jegas.com wrote: Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) Is 'hours' an exaggeration, or is that really what you're seeing? On a modern machine like that, the gcc build should be something like five minutes... Well 5 minutes is pretty quick. I have: Chapter 5 [gcc-pass1] 8 minutes and 22 seconds Chapter 5 [gcc-pass2] 11 minutes and 37 seconds Chapter 6 [gcc ] 78 minutes and 35 seconds Using only 1 core for consistent timing. Yes, but that's using a single core, which I'd never be doing on a machine like the one described - running -j8 sounds perfectly reasonable. However, it occurs to me that when I said 5 minutes, that would have excluded tests, since my automated builds skip them. Can't remember how effectively those can be parallelized, but I'd still not expect even the Chapter 6 gcc build to take more than 20 minutes... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) Is 'hours' an exaggeration, or is that really what you're seeing? On a modern machine like that, the gcc build should be something like five minutes... Well 5 minutes is pretty quick. I have: Chapter 5 [gcc-pass1] 8 minutes and 22 seconds Chapter 5 [gcc-pass2] 11 minutes and 37 seconds Chapter 6 [gcc ] 78 minutes and 35 seconds Using only 1 core for consistent timing. Yes, but that's using a single core, which I'd never be doing on a machine like the one described - running -j8 sounds perfectly reasonable. However, it occurs to me that when I said 5 minutes, that would have excluded tests, since my automated builds skip them. Can't remember how effectively those can be parallelized, but I'd still not expect even the Chapter 6 gcc build to take more than 20 minutes... Simon. I was trying to give you folks new numbers now that I seem to have my scripts almost in stone ... but I fell asleep for 12 hours (happens after all these 24+ hour marathons I do... programming, or doing this LFS stuff.. I tend to do that). For me, I've taken Barry's advice (He helped write the book so it might be his advice) Where is says these tests don't matter... I don't pay much attention. When the book says Sanity Check - Run these tests - its critical? I just do it. Maybe I'll get daring after awhile and make a way to set a variable (export RUNLFSTEST=true) or something, and make the script make a decision on how it launches the makes and configure scripts. For now, I'm happy I can get the OS to compile and boot. I still have things I'm working on, but I'm pretty much overall pleased with the LFS book and the community. As for my gcc taking awhile, it is the tests and I didn't mean to exaggerate if I did - I would say its at least compile + testing .. around 45 minutes (double if I run twice because of errors) but that DOES include the testing which is what seems to take the longest. --Jason -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Mon, 2012-01-09 at 08:57 -0700, jasonps...@jegas.com wrote:
Now, I wouldn't care that much except even running on a DEDICATED 32bit
Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES...
it takes a while... So running the procedure twice is time
consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core
with hyper-threading - its like having EIGHT CPU)
Is 'hours' an exaggeration, or is that really what you're seeing? On a
modern machine like that, the gcc build should be something like five
minutes...
Simon.
No exaggeration - but there are a few steps in the process. I'm going to
PASTE the SPECIFIC
script that takes forevers and fails, then when run again PASSES. And
yeah - it takes a long
time. As Does glibc - I think the kernel isn't actually so bad... these
are the worst two...
there are some others - but they are bunched together in such a way I
just leave and return when the whole gambit completes.
PREPARE for my GCC SCRIPT (Hopefully it doesn't word wrap)
PASTEBEGIN
#!/tools/bin/bash
echo --
echo SCRIPT ASSUMES YOU ARE ALREADY IN CHROOT
echo WITH RECOMMENDED SETTINGS APPLIED SUGGESTED
echo IN PREVIOUS SCRIPT - See 08-root.sh and 09-chroot.sh
echo For info on binding dev, kernel virt files sys and chroot.
echo --
echo STOP NOW IF REQUIREMENTS NOT MET - With Ctrl+C
echo --
$LFS/lfs7/Jegas/readline
#
echo 6.17. GCC-4.6.1
#/lfs7/Jegas/readline
#
cd /sources
rm -R gcc-4.6.1
tar -xjvf gcc-4.6.1.tar.bz2
cd gcc-4.6.1
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/ -fomit-frame-pointer/' \
gcc/Makefile.in ;;
esac
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
patch -Np1 -i ../gcc-4.6.1-locale-1.patch
rm -R ../gcc-build
mkdir -v ../gcc-build
cd ../gcc-build
../gcc-4.6.1/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languages=c,c++ \
--disable-multilib --disable-bootstrap --with-system-zlib
make
ulimit -s 16384
make -k check
../gcc-4.6.1/contrib/test_summary
# For only the summaries, pipe the output through grep -A7 Summ.
#Results can be compared with those located at
http://www.linuxfromscratch.org/lfs/build-logs/7.0/ and http://gcc.gnu.
#org/ml/gcc-testresults/.
make install
ln -sv ../usr/bin/cpp /lib
ln -sv gcc /usr/bin/cc
#
echo SANITY CHECKS
#/lfs7/Jegas/readline
#
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
echo Desired Result: [Requesting program interpreter:
/lib/ld-linux.so.2]
/lfs7/Jegas/readline
#
#
#Now make sure that we're setup to use the correct startfiles:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crt1.o succeeded
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crti.o succeeded
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crtn.o succeeded
echo Depending on your machine architecture, the above may differ
slightly
echo the difference usually being the name of the directory after
/usr/lib/gcc.
echo If your machine is a 64-bit system, you may also see a directory
named lib64
echo towards the end of the string. The important thing to look for here
is that
echo gcc has found all three crt*.o files under the /usr/lib directory.
echo Verify that the compiler is searching for the correct header files:
/lfs7/Jegas/readline
#
#
grep -B4 '^ /usr/include' dummy.log
echo Desired Results: #include ... search starts here:
echo Desired Results: /usr/local/include
echo Desired Results: /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/include
echo Desired Results: /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/include-fixed
echo Desired Results: /usr/include
echo Again, note that the directory named after your target triplet may
be different
echo than the above, depending on your architecture.
/lfs7/Jegas/readline
#
#
echo Next, verify that the new linker is being used with the correct
search paths:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
echo Desired Results: SEARCH_DIR[/usr/i686-pc-linux-gnu/lib]
echo Desired Results: SEARCH_DIR[/usr/local/lib]
echo
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Jan 10, 2012 9:03 AM, jasonps...@jegas.com wrote:
On Mon, 2012-01-09 at 08:57 -0700, jasonps...@jegas.com wrote:
Now, I wouldn't care that much except even running on a DEDICATED 32bit
Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES...
it takes a while... So running the procedure twice is time
consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core
with hyper-threading - its like having EIGHT CPU)
Is 'hours' an exaggeration, or is that really what you're seeing? On a
modern machine like that, the gcc build should be something like five
minutes...
Simon.
No exaggeration - but there are a few steps in the process. I'm going to
PASTE the SPECIFIC
script that takes forevers and fails, then when run again PASSES. And
yeah - it takes a long
time. As Does glibc - I think the kernel isn't actually so bad... these
are the worst two...
there are some others - but they are bunched together in such a way I
just leave and return when the whole gambit completes.
PREPARE for my GCC SCRIPT (Hopefully it doesn't word wrap)
PASTEBEGIN
#!/tools/bin/bash
echo --
echo SCRIPT ASSUMES YOU ARE ALREADY IN CHROOT
echo WITH RECOMMENDED SETTINGS APPLIED SUGGESTED
echo IN PREVIOUS SCRIPT - See 08-root.sh and 09-chroot.sh
echo For info on binding dev, kernel virt files sys and chroot.
echo --
echo STOP NOW IF REQUIREMENTS NOT MET - With Ctrl+C
echo --
$LFS/lfs7/Jegas/readline
#
echo 6.17. GCC-4.6.1
#/lfs7/Jegas/readline
#
cd /sources
rm -R gcc-4.6.1
tar -xjvf gcc-4.6.1.tar.bz2
cd gcc-4.6.1
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/ -fomit-frame-pointer/' \
gcc/Makefile.in ;;
esac
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
patch -Np1 -i ../gcc-4.6.1-locale-1.patch
rm -R ../gcc-build
mkdir -v ../gcc-build
cd ../gcc-build
../gcc-4.6.1/configure --prefix=/usr \
--libexecdir=/usr/lib --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languages=c,c++ \
--disable-multilib --disable-bootstrap --with-system-zlib
make
ulimit -s 16384
make -k check
../gcc-4.6.1/contrib/test_summary
# For only the summaries, pipe the output through grep -A7 Summ.
#Results can be compared with those located at
http://www.linuxfromscratch.org/lfs/build-logs/7.0/ and http://gcc.gnu.
#org/ml/gcc-testresults/.
make install
ln -sv ../usr/bin/cpp /lib
ln -sv gcc /usr/bin/cc
#
echo SANITY CHECKS
#/lfs7/Jegas/readline
#
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose dummy.log
readelf -l a.out | grep ': /lib'
echo Desired Result: [Requesting program interpreter:
/lib/ld-linux.so.2]
/lfs7/Jegas/readline
#
#
#Now make sure that we're setup to use the correct startfiles:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crt1.o succeeded
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crti.o succeeded
echo Desired Results:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../crtn.o succeeded
echo Depending on your machine architecture, the above may differ
slightly
echo the difference usually being the name of the directory after
/usr/lib/gcc.
echo If your machine is a 64-bit system, you may also see a directory
named lib64
echo towards the end of the string. The important thing to look for here
is that
echo gcc has found all three crt*.o files under the /usr/lib directory.
echo Verify that the compiler is searching for the correct header files:
/lfs7/Jegas/readline
#
#
grep -B4 '^ /usr/include' dummy.log
echo Desired Results: #include ... search starts here:
echo Desired Results: /usr/local/include
echo Desired Results: /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/include
echo Desired Results: /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/include-fixed
echo Desired Results: /usr/include
echo Again, note that the directory named after your target triplet may
be different
echo than the above, depending on your architecture.
/lfs7/Jegas/readline
#
#
echo Next, verify that the new linker is being used with the correct
search paths:
grep
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Tue, 10 Jan 2012 09:21:01 + Firerat fire...@googlemail.com wrote: I find that if a make fails first time, but completes (or gets further ) on second run it is due to some race condition where you have multiple jobs and a new job thread is dependent on something that hasn't completed. The simplest way around this is to flag the make with -j1 FWIW I've never had a problem compiling gcc with make -j4 Also, if you read his script he doesn't use multiple jobs when he runs: make -k check If you are having trouble with slow builds then have a look at top on your host system and see if anything is eating CPU and/or memory. I have had problems with polkitd and nautilus on Ubuntu (bad pulseaudio setup) Chrome is also a mem/CPU hog, especially if flash is enabled Are you compiling in a virtual machine? If so, perhaps it is not making all the system's resources available? Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Tue, Jan 10, 2012 at 10:50 AM, Andrew Benton b3n...@gmail.com wrote: On Tue, 10 Jan 2012 09:21:01 + Firerat fire...@googlemail.com wrote: I find that if a make fails first time, but completes (or gets further ) on second run it is due to some race condition where you have multiple jobs and a new job thread is dependent on something that hasn't completed. The simplest way around this is to flag the make with -j1 FWIW I've never had a problem compiling gcc with make -j4 Also, if you read his script he doesn't use multiple jobs when he runs: make -k check true, however we have no idea if MAKEFLAGS has been set actually, read the fist post, he is using MAKEFLAGS=-j8 and I too have no issues compiling gcc with -j14 ( yes 14 ) in any case -j1 removes the doubt from the equation, is it a make race condition or not? also -j1 makes it much easier to read what went wrong, you are reading just one job and not 4 , 5 or 6 jobs at the same time. And, yes I'f I recall correctly one of his earlier posts last week mentioned use of a VM ( windows hosting slackware ) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
I find that if a make fails first time, but completes (or gets further ) on second run it is due to some race condition where you have multiple jobs and a new job thread is dependent on something that hasn't completed. The simplest way around this is to flag the make with -j1 FWIW I've never had a problem compiling gcc with make -j4 Also, if you read his script he doesn't use multiple jobs when he runs: make -k check ACTUALLY - MAKEFLAGS set to 8 in my Root .bash_profile to make sure It was always in play. Race condition thing though may apply. I'm using a REAL PC now, but even when I use a Virtual MAchine I generally set 2 or more processes and set MAKE Flags accordingly. If you are having trouble with slow builds then have a look at top on your host system and see if anything is eating CPU and/or memory. I have had problems with polkitd and nautilus on Ubuntu (bad pulseaudio setup) Chrome is also a mem/CPU hog, especially if flash is enabled Are you compiling in a virtual machine? If so, perhaps it is not making all the system's resources available? Andy Not now I'm not - I kind of got tired of waiting and configured my fastest machine for dual boot Win7/Slackware (32bit for making 32 bit LFS) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On 1/10/2012 6:34 AM, jasonps...@jegas.com wrote: I find that if a make fails first time, but completes (or gets further ) on second run it is due to some race condition where you have multiple jobs and a new job thread is dependent on something that hasn't completed. The simplest way around this is to flag the make with -j1 FWIW I've never had a problem compiling gcc with make -j4 Also, if you read his script he doesn't use multiple jobs when he runs: make -k check ACTUALLY - MAKEFLAGS set to 8 in my Root .bash_profile to make sure It was always in play. Race condition thing though may apply. I'm using a REAL PC now, but even when I use a Virtual MAchine I generally set 2 or more processes and set MAKE Flags accordingly. If you are having trouble with slow builds then have a look at top on your host system and see if anything is eating CPU and/or memory. I have had problems with polkitd and nautilus on Ubuntu (bad pulseaudio setup) Chrome is also a mem/CPU hog, especially if flash is enabled Are you compiling in a virtual machine? If so, perhaps it is not making all the system's resources available? Andy Not now I'm not - I kind of got tired of waiting and configured my fastest machine for dual boot Win7/Slackware (32bit for making 32 bit LFS) If you wanted to go back to a virtual machine, check EVERY tab on EVERY page. Oracle VirtualBox hides a critical option on a separate tab of the System page. I only found out about it when some of the ISOs I was testing wouldn't boot without it checked.. Elly -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
If you wanted to go back to a virtual machine, check EVERY tab on EVERY page. Oracle VirtualBox hides a critical option on a separate tab of the System page. I only found out about it when some of the ISOs I was testing wouldn't boot without it checked.. Elly Thank You Elly - I DO Actually - and I plan too... as soon as I think I'm past my semi-frequent COMPLETE REBUILDS. Then VM Speed will be plenty. The speed difference is noticeable with video games... (we all knew this) ... but compiling? Compiling an OS? YES Resounding YES lol Thank You for tip and I hope you have great day today! --Jason -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
Simon Geard wrote: On Mon, 2012-01-09 at 08:57 -0700, jasonps...@jegas.com wrote: Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) Is 'hours' an exaggeration, or is that really what you're seeing? On a modern machine like that, the gcc build should be something like five minutes... Well 5 minutes is pretty quick. I have: Chapter 5 [gcc-pass1] 8 minutes and 22 seconds Chapter 5 [gcc-pass2] 11 minutes and 37 seconds Chapter 6 [gcc ] 78 minutes and 35 seconds Using only 1 core for consistent timing. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
Hello All, I know it's me again - I feel like I'm maybe being a pill by now. But this one is strange, and I'm not sure whether to just accept the successful compile and move on or be concerned because what I'm experiencing is possibly a symptom of a major mistake somewhere along the line. As the LFS 7 book suggests, I remove the source code folder before a compile, and extract the source code for the package I'm about to compile fresh - so everything is prestine. Well... I do thing for the LAST gcc compile in the book, the one where you are root but chroot'd in. I remove the source folder, I extract, I remove the gcc_build folder, I make it again new... in short I follow all the recommendations... Then come all the sanity checks... well they aren't sane at all. Frustrated... I execute the same exact steps again on a whim.. exactly... remove the directories, extract the new source code... compile... 100% SUCCESSFULL .What in the world? Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) So - Should I be worried? Does anyone have a clue how that could happen? Does Anyone want to see the Script that I run TWICE (and it has all the clean up etc and source code un-tarring)? Any help is always appreciated! Thank You... --Jason -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Mon, Jan 9, 2012 at 4:57 PM, jasonps...@jegas.com wrote: Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) You should know better that hyper-threading is far from having 8 real cores, you're compile time is probably nearly the same as with hyper-threading disabled. So - Should I be worried? Does anyone have a clue how that could happen? Does Anyone want to see the Script that I run TWICE (and it has all the clean up etc and source code un-tarring)? Any help is always appreciated! Thank You... --Jason Did you read section 4.5 About SBUs?[1]. It says that average compile time is measured depending on how long it took you to compile the very first package. GCC in chapter 6 (6.17) says: Approximate build time: 47 SBU, so if your binutils package took 10 minutes, your GCC compilation would take about 47*10 = 470 minutes, almost 8 hours. Matijn [1] http://www.linuxfromscratch.org/lfs/view/stable/chapter04/aboutsbus.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
From: Matijn Woudt tijn...@gmail.com Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) You should know better that hyper-threading is far from having 8 real cores, you're compile time is probably nearly the same as with hyper-threading disabled. I Don't Doubt that for a second... MY Wife and I were talking just today that we think 6 AMD REAL cores is probably better than Intel's i7 4 with Hyper-threading as a guy who wrote an assembly language OS when I was only 20, I know that the CPU is still chowing cycles to switch tasks - regardless how Well they wired it and called it Hyper - it's a a TASK SWITCH. So - Should I be worried? Does anyone have a clue how that could happen? Does Anyone want to see the Script that I run TWICE (and it has all the clean up etc and source code un-tarring)? Any help is always appreciated! Thank You... --Jason Did you read section 4.5 About SBUs?[1]. It says that average compile time is measured depending on how long it took you to compile the very first package. GCC in chapter 6 (6.17) says: Approximate build time: 47 SBU, so if your binutils package took 10 minutes, your GCC compilation would take about 47*10 = 470 minutes, almost 8 hours. Matijn Um, yeah, been through the book numerous times now - wrote in in this original thread lol. MY worry is that I compile gcc this final go around, it fails. I clean up the directories and do it again... and it works. Time waise as you point out... fast CPU or not - IT TERRIBLE and makes a grown man want to cry... or at least grumble lol :) Stay Cool Matijn P.S. I'm really close to another boot and I have high hopes it will work halfway decent! How is your LFS system going? You have one built yet? How'd that go? Did you help with the book or something too? Regardless - have a great day and thank you for replying! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Mon, Jan 9, 2012 at 8:49 PM, jasonps...@jegas.com wrote: From: Matijn Woudt tijn...@gmail.com So - Should I be worried? Does anyone have a clue how that could happen? Does Anyone want to see the Script that I run TWICE (and it has all the clean up etc and source code un-tarring)? Any help is always appreciated! Thank You... --Jason Did you read section 4.5 About SBUs?[1]. It says that average compile time is measured depending on how long it took you to compile the very first package. GCC in chapter 6 (6.17) says: Approximate build time: 47 SBU, so if your binutils package took 10 minutes, your GCC compilation would take about 47*10 = 470 minutes, almost 8 hours. Matijn Um, yeah, been through the book numerous times now - wrote in in this original thread lol. MY worry is that I compile gcc this final go around, it fails. I clean up the directories and do it again... and it works. Time waise as you point out... fast CPU or not - IT TERRIBLE and makes a grown man want to cry... or at least grumble lol :) If you're having trouble compiling it, then you should post errors you got. If everything went OK the second time (including the test suite), then there's probably nothing to worry about. Stay Cool Matijn P.S. I'm really close to another boot and I have high hopes it will work halfway decent! How is your LFS system going? You have one built yet? How'd that go? Did you help with the book or something too? I have built LFS a few times, 6.1, 6.3, 6.4 and 6.7 to be exactly. Haven't built 7.0 because I don't have time to manage all stuff by myself now. Packages are updating way too fast, so I went back to Ubuntu. Though, I might start LFS soon again, I probably have to build a linux system for a embedded ARM system, and I think LFS will work too (with cross compiler ofcourse). If you need any help, feel free to ask! Matijn -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Mon, Jan 09, 2012 at 03:09:49PM -0600, Bruce Dubbs wrote: Even my old 2005 P4 does binutils in 135 seconds. For LFS-7.0 building itself, my 2.4GHz athlon64 took 150 seconds (with a 1rpm drive and not using cpufreq, the bios is too crap), my 2.2GHz version (7200rpm, and ondemand cpufreqgovernor) took 188 seconds. As always, building from an earlier toolchain will give a shorter initial SBU but doesn't make a lot of odds in the overall build time. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!
On Mon, 2012-01-09 at 08:57 -0700, jasonps...@jegas.com wrote: Now, I wouldn't care that much except even running on a DEDICATED 32bit Linux (Slackware 13.37) with MAKEFLAGS set to EIGHT to use all CORES... it takes a while... So running the procedure twice is time consuming.. We're talking hours on a new i7 DELL XPS Studio (Quad Core with hyper-threading - its like having EIGHT CPU) Is 'hours' an exaggeration, or is that really what you're seeing? On a modern machine like that, the gcc build should be something like five minutes... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
