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) > > PASTE----------------------------------------------------BEGIN > #!/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 Desired Results: SEARCH_DIR["/lib"] > echo Desired Results: SEARCH_DIR["/usr/lib"]; > echo A 64-bit system may see a few more directories. > echo For example, here is the output from an x86_64 machine: > echo Desired 64 Results: > SEARCH_DIR["/usr/x86_64-unknown-linux-gnu/lib64"] > echo Desired 64 Results: SEARCH_DIR["/usr/local/lib64"] > echo Desired 64 Results: SEARCH_DIR["/lib64"] > echo Desired 64 Results: SEARCH_DIR["/usr/lib64"] > echo Desired 64 Results: SEARCH_DIR["/usr/x86_64-unknown-linux-gnu/lib"] > echo Desired 64 Results: SEARCH_DIR["/usr/local/lib"] > echo Desired 64 Results: SEARCH_DIR["/lib"] > echo Desired 64 Results: SEARCH_DIR["/usr/lib"]; > /lfs7/Jegas/readline > #-------------------------------------------------------- > > #-------------------------------------------------------- > echo Next make sure that we are using the correct libc: > grep "/lib.*/libc.so.6 " dummy.log > echo Desired Result: attempt to open /lib/libc.so.6 succeeded > /lfs7/Jegas/readline > #-------------------------------------------------------- > > #-------------------------------------------------------- > echo Lastly, make sure GCC is using the correct dynamic linker: > grep found dummy.log > echo Desired Result: found ld-linux.so.2 at /lib/ld-linux.so.2 > echo if missing - we have major problems. > /lfs7/Jegas/readline > #-------------------------------------------------------- > > #-------------------------------------------------------- > echo Once everything is working correctly, clean up the test files: > rm -v dummy.c a.out dummy.log > #-------------------------------------------------------- > echo IF TESTS FAIL - RUN THIS SCRIPT AGAIN > echo . > echo If Tests PASSED, run 12-chroot.sh > PASTE----------------------------------------------------END > >
> > -- 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 Btw, a significant proportion of the time is with the make -k check, still it shouldn't take hours, but it is dependent on your CPU load, memory etc.. 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
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
