ch. 6.14: GCC-3.4.4 `make -k check' and coreutils dummy failure

Ken Moffat ken at kenmoffat.uklinux.net
Thu Jun 30 08:30:45 PDT 2005


On Thu, 30 Jun 2005, Roel Kluin wrote:

> Thanks for your time to read this. I really like LFS book, its a good source
> of information on this operating system.
> after a "make -k check", I got the error stated directly below. Not sure
> whether this was a serious problem, I continued, but wasn't able to make the
> dummy in the next chapter (Coreutils-5.2.1) that error is further below
>
> make[3]: *** [check-DEJAGNU] Error 1
> make[3]: Leaving directory
> `/sources/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite'
> make[2]: *** [check-am] Error 2
> make[2]: Target `check' not remade because of errors.
[snip]
> make[2]: Leaving directory
> `/sources/gcc-build/i686-pc-linux-gnu/libiberty/testsuite'
> make[1]: Leaving directory `/sources/gcc-build/i686-pc-linux-gnu/libiberty'
> make: Target `check' not remade because of errors.
>

 In what you've shown us, the only errors relate to check-DEJAGNU and
the libstdc++ testsuite - I seems to remember that other tests usually
run before this.  What you've shown us doesn't really tell us anything.
Did you run ../gcc-3.4.4/contrib/test_summary afterwards (as advised in
chapter 5) ?  We *expect* make check to fail here, that's why we supply
the -k flag, the question is if you got an abnormal number of errors.

>
> running `src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"'
>
> root:/sources/coreutils-5.2.1# src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes
> check"
> Making check in lib
> make[1]: Entering directory `/sources/coreutils-5.2.1/lib'
> make  check-am
> make[2]: Entering directory `/sources/coreutils-5.2.1/lib'
> make[2]: Warning: File `/usr/include/sys/types.h' has modification time
> 7.7e+04 s in the future

 That is your problem - this file is dated in the future, which causes
acl.c to be remade, only as user 'dummy' you lack permission.

> if gcc -DHAVE_CONFIG_H -DLIBDIR=\"/usr/lib\" -I. -I. -I..  -I.. -I.   -g -O2
> -MT acl.o -MD -MP -MF ".deps/acl.Tpo" -c -o acl.o acl.c; \
> then mv -f ".deps/acl.Tpo" ".deps/acl.Po"; else rm -f ".deps/acl.Tpo"; exit
> 1; fi
> acl.c:63: fatal error: opening dependency file .deps/acl.Tpo: Permission
> denied
[snip]


 The thing you need to find out is what caused that header to have a bad
date.  Some initial questions, to try to establish the facts:

 What shows up for 'ls -l /usr/include/sys/types.h' in chroot ?  (I'm
never any good at guessing how much time is represented by 7.7e+04
seconds)

 Do any other dates in the new system look equally odd ?

 Do you have a log of the glibc testsuite ?

 This is the testing book ?  Did you change the versions of any
packages ?

 Which kernel are you running, and from which distro if you didn't
compile it yourself ?

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce




More information about the lfs-support mailing list