[lfs-support] Final GCC Compile Weirdness - 1 Time? No, 2 nd Time? Perfect!

Firerat firer4t at googlemail.com
Tue Jan 10 01:21:01 PST 2012


On Jan 10, 2012 9:03 AM, <jasonpsage at jegas.com> wrote:
>
> >>On Mon, 2012-01-09 at 08:57 -0700, jasonpsage at 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 at -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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20120110/2c7d76c4/attachment.html>


More information about the lfs-support mailing list