[Clfs-dev] Sanity checks

[Jim Gifford]

Akira Urushibata wrote:
> It is not possible to run checks that come with the packages during the
> early stages of CLFS.  As a result, errors may go unnoticed for a while.
> When they show up, one has to go back and do things over again.  When the
> exact cause of the error cannot be determined, one has to start anew from
> the beginning.
>
> I'd like to share some techniques to address this problem.
>   
>
> First I'd like to outline what the typical errors are.
>
> 1)  Simple typos
>     example:  ./configure --prefix=/ussr
>
> 3)  Skipping a specific command
>     example: omitting "make install"
>
> 2)  Skipping an entire page
>
> 3)  Confusing pages from different stages
>     GCC is built four times in CLFS 1.1.
>     Binutils is built three times.
>     
> The tests (for CLFS 1.1) listed below should help bring mistakes to light.
>
>
> 1. Examine installed binary executables with file.
>
> Programs in /clfs/cross-tools/bin are executables for the host system.
> Programs in /clfs/tools/bin are for the target system.
>
> If you build a 64-bit target system on a 32-bit host system,
> /cross-tools/bin should contain 32 bit executables and /tools/bin
> should contain 64-bit executables.  You can check this with the file
> utility, which is built at the beginning of chapter 5.
>
>
> 2. Execute programs and make sure that they work.
>
> Programs in /clfs/cross-tools/bin should run on the host system.
> You can check them by doing things like:
>
> /clfs/cross-tools/bin/file --version
> /clfs/cross-tools/bin/**-**-**-cc --version
>
>
> 3.  Trying out GCC with a trivial test program.
>
> First write a short program, say one that just prints a message.
> Example "test.c":
>
> main(){ printf("Hello! %d\n"); }
>
> The static cross-gcc built in 5.8 should get to the assembly stage:
>
> $ /mnt/clfs/cross-tools/bin/**-**-**-gcc -m64 -S test.c
>
> This will emit one warning:
>
> test.c: In function 'main':
> test.c:1: warning: incompatible implicit declaration of built-in function 'printf'
>
> You should see 64 bit registers %rsp, %rbp, etc. in the assembly listing
> "test.s" .
>
> The final cross-gcc from 5.11 produces a working binary executable.
> Use the file utility to check that the resulting output is in the right format:
>
> $ /mnt/clfs/cross-tools/bin/**-**-**-gcc -m64 test.c -o test
> $ /mnt/clfs/cross-tools/file test
>
>
> If you already have a 64-bit system somewhere, you can take the binary
> executable there and try running it on it.
>
> We want a stand-alone executable so we compile static:
>
> $ /mnt/clfs/cross-tools/bin/**-**-**-gcc -m64 --static test.c -o test
>
>
> 4:  Examining the linkmap
>
> The linkmap is a file optionally produced by the link-loader (ld) which
> contains information on what files were loaded to resolve external symbols.
> We can use this feature to check the cross-compiler built in 5.11.
>
> The following makes a link map file named "Linkmap":
>
> $ /mnt/clfs/cross-tools/bin/**-**-**-gcc test.c \
>   -Xlinker "-Map" -Xlinker "Linkmap"
> $ grep "LOAD" Linkmap    # Reports loaded object files and libraries
> $ rm a.out
> $ rm Linkmap
>
> Here is a shortcut:
>
> $ /mnt/clfs/cross-tools/bin/**-**-**-gcc test.c -o /dev/null \
>   -Xlinker "-M" | grep "LOAD"
>
>
> No library files from the host system should be reported here.
> The library files should be the ones in "/tools/": "/tools/lib" and
> so on.  We also see some files from "/cross-tools/".  These are run-time
> initialization files ("crti.o" and such) and libraries which come with
> the GCC package.
>
> It is instructive to compile the same test.c with your host-system gcc,
> create a link map and observe the changes.
>
> $ /usr/bin/gcc test.c -o /dev/null -Xlinker "-M"  | grep "LOAD"
>
> Also try this at right after boot or chroot, after installation of the
> final GCC, and after the specs file modification.
>
>
> 5. Check for existence of utilities with whereis.
>
> 5.1  Check for well-known utilities:
>
> $ for i in as od strip gprof gcc bash \
>   ls date md5sum diff find locate \
>   gawk awk msgfmt grep gzip zcat \
>   make patch sed tar info lsmod \
>   hwclock \
>   flex ps perl ping ftp vim less man
>     do
>     whereis -b $i -B /bin /sbin /tools/bin /tools/sbin
>     done
>
> Do this after boot or chroot, to assure that all the necessary utilities
> are in place.  You can throw in whatever else you please.
>
> At the end of chapter 10, do it again, but change one line:
>
>     whereis -b $i -B /bin /sbin /usr/bin /usr/sbin
>
>
> These programs are not available just after boot/chroot:
>
>   flex ps perl ping ftp vim less man 
>
>
> 5.2  Thorough whereis test.
>
> This is like the one above, only that it scans through the book to find
> "installed programs".
>
> $ sed -n '/Installed programs:/,/<\/span>$/p' CLFS-BOOK.html |
>   grep -v "Installed programs" |
>   sed -e 's@</span>@,\n@' -e 's@<span class="segbody">@\n@' |
>   tr '\n' ' ' |
>   sed -e 's/,\| and /\n/g' |
>   sed -e '/^ *$/d' -e 's/^ *//' -e 's/  */ /g' > list
>
> $ cut -d' ' -f 1 list | while read i           # cut, not cat; see below
>     do
>     whereis -b $i
>     done
>
> The file "list" above reports links like this:
>
>   c++
>   cc (link to gcc)
>   cpp
>
> The whereis utility is in the Util-linux-ng package.
>
> Doing the above, I discovered that tack (from Ncurses) and resizecons (Kbd)
> are not installed, contrary to what is written in the Book.
>
>
>
> 6.  Examine linked libraries with readelf.
>
> find /bin /sbin /etc /lib /lib64 /usr -type f -perm /111 | while read i
>   do
>   readelf -h $i > /dev/null 2>&1 && echo -n $i && readelf -e $i |
>   fgrep "[Requesting";  echo ""
>   done
>
> Make sure there are no binaries linked to libraries in "/tools/".
>
> Some files will report no library link request.  These are libraries
> themselves or statically linked executables.
>
>
>
> 7.  Turning off write permission of "/cross-tools/" and "/tools/"
>
> No new files are written into "/cross-tools/" in Chapter 6 and onward.
>
> After boot or chroot, no files in "/cross-tools/" are accessed.
>
> No new files are created in "/tools/" in Chapter 10 and onward.  Only one
> write access to "/tools/" happens during Chapter 10, namely the specs file
> adjustment in 10.9.
>
> The above can be checked by examining the ctime and atime.  A more certain
> way would be to turn off read/write permission at the directory stem
> at the appropriate moment.  The latter is recommended for access time
> is by no means easy to keep track of.
>
> Several actions trigger access.  When you check file type with file,
> it counts as a read access.  If you strip symbols off an executable, the
> event is recorded as a creation of new file.  Any copy is a read access,
> and each an every ls is a directory read access.  We can't keep track of
> all this so we encounter numerous "mysterious accesses" when we give
> "ls -l --time=a" a try - and then (usually) give up.  For details consult
> the manual pages of "file", "strip", "ls", etc.
>
> ---
>
> Thank you for reading.  I hope this helps.  I feel people need tangible
> methods to check progress as they work through the build process.
>
> As I am new to this list, I'd very much appreciate instructions on how
> this material can be incorporated into coming versions of CLFS books.
> Though the above is for CLFS 1.1, I am sure some parts are valid for
> (plain) LFS as well.
>
>
> _______________________________________________
> Clfs-dev mailing list
> Clfs-dev at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
>   
I like your idea, maybe you can add it to hints.cross-lfs.org, the dev 
team can have the full picture.