Building LFS on a 64-bit system (long)

Bruce Dubbs bruce.dubbs at gmail.com
Mon Aug 17 10:30:51 PDT 2009


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 ========







More information about the lfs-dev mailing list