I just got a shinny new Core2 Duo based system and, of course, the first thing I did was build an LFS system for it. Below are some of my observations, some of which may need to be addressed in the book. This post is for the purposes of discussion.
Generally things went just fine. I was able to boot up the first time I tried. I've now built 6.5 both manually and via jhalfs. I am concerned aout some of the test suite errors. -- Bruce 1. We probably need a section in the Preface to address 32- vs 64-bit issues. We can build a 64-bit system, but it is not multi-lib. we need to point out some of the potential problems here. I'm not sure what issues we may run into and we may not have problems for a pure LFS/BLFS system, but I think there may be issues if someone wants to use a pre-compiled binary. 2. In Chapter 5, Adjusting the Toolchain, we have the comment: "If everything is working correctly, there should be no errors, and the output of the last command will be of the form: [Requesting program interpreter: /tools/lib/ld-linux.so.2] Note that /tools/lib, or /tools/lib64 for 64-bit machines appears as the prefix of the dynamic linker." I think that perhaps we should be more explicit about the filename for 64-bit systems. /tools/lib64/ld-linux-x86-64.so.2 3. In section 5.10, GCC-4.4.1 - Pass 2, the same comment as #2 above applies. 4. In section 6.9, Glibc-2.10.1, the comments about the tests need to be updated. For instance, there is not longer a 'nptl/tst-clock2' test. It appears that the ntpl/ directory has been renamed to rt/. I got conflicting issues in the error checks. I did get the usual posix/annexc failure, but I also had a rt/tst-clock2 error when building manually, but not when building via jhalfs. This was one of the timeout errors mentioned, but it's certainly not an "older and slower hardware" system. 5. In section 6.10, Re-adjusting the Toolchain, we may want to be more explicit about the output for 64-bit systems. We do have the comment "(allowing for platform-specific differences in dynamic linker name)" and similar in a couple of places, but we ask the new user to guess if the results are correct. 6. The same comments to #2 above apply to parts of section 6.15, GCC-4.4.1, although we do have one explicit 64-bit output example. We probably should be more consistent here and have 64-bit output for each set of example output. Also, I saw some test errors I haven't seen before: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE ERROR: tcl error sourcing /sources/gcc-4.4.1/gcc/testsuite/gcc.misc-tests/linkage.exp. ERROR: couldn't execute "file": no such file or directory FAIL: gcc.target/i386/avx-vmovntdq-256-1.c (test for excess errors) WARNING: gcc.target/i386/avx-vmovntdq-256-1.c compilation failed to produce executable FAIL: gcc.target/i386/avx-vmovntpd-256-1.c (test for excess errors) WARNING: gcc.target/i386/avx-vmovntpd-256-1.c compilation failed to produce executable FAIL: gcc.target/i386/avx-vmovntps-256-1.c (test for excess errors) WARNING: gcc.target/i386/avx-vmovntps-256-1.c compilation failed to produce executable The first two errors may just be a testsuite error that we could fix with a sed. (I haven't tried.) Perhaps we need to either add 'file' to Chapter 5 or move it up before GCC in Chapter 6. I haven't seen the avx-vmovnt* errors before. They may be related to the 64-bit instruction set. I did find examples of the errors on http://gcc.gnu.org/ml/gcc-testresults/. Doing some research, it appears that this has something to do with the x86_64 instruction set and it is not defining some #ifdefs right, but I don't know enough about it to trace it down. I also had the common libmudflap errors. 7. e2fsprogs had 4 failures: d_loaddump: debugfs load/dump test: ../../tests/d_loaddump/script: line 22: 23505 Segmentation fault $DEBUGFS -R "write $TEST_DATA test_data" -w $TMPFILE >> $OUT.new 2>&1 ../../tests/d_loaddump/script: line 34: 23509 Segmentation fault $DEBUGFS -R "dump test_data $VERIFY_DATA" $TMPFILE >> $OUT.new 2>&1 f_imagic_fs: imagic filesystem with imagic inodes: ../../tests/run_e2fsck: line 48: 24950 Segmentation fault $DEBUGFS -w -R "feature imagic_inodes" $TMPFILE > /dev/null 2>&1 f_dup4: find all directory pathnames: ../../tests/f_dup4/script: line 41: 24241 Segmentation fault $DEBUGFS -w $TMPFILE > /dev/null 2>&1 <<EOF 8. coreutils had 1 failure: FAIL: cp/cp-mv-enotsup-xattr This may be a kernel configuration issue: # CONFIG_EXT2_FS is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y 9. automake failed 1 test FAIL: acloca22.test 10. file failed one test /bin/sh: line 5: 15193 Segmentation fault ${dir}$tst FAIL: stackoverflow2 11. gawk failed 3 tests ======== Starting machine-specific tests ======== double1 ./double1.ok _double1 differ: char 1, line 1 make[2]: [double1] Error 1 (ignored) double2 ./double2.ok _double2 differ: char 247, line 4 make[2]: [double2] Error 1 (ignored) fmtspcl intformat ./intformat.ok _intformat differ: char 1, line 1 make[2]: [intformat] Error 1 (ignored) ======== Done with machine-specific tests ======== -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
