On Sun, Jan 07, 2007 at 07:52:55AM -0800, Zeb Packard wrote:
> I'm using the more_control helpers method of package management with
> 6.2 on running 'make -k check' on gcc my gcc summary is as such:
>
> ####################################################
> === gcc Summary ===
>
> # of expected passes 35543
> # of unexpected failures 1
> # of unexpected successes 3
> # of expected failures 92
> # of untested testcases 28
> # of unsupported tests 326
> ####################################################
I think that 1 failure from 35544 tests (or pedantically 1 difference
from the log you are comparing to) is no big deal. If you see 10,
perhaps. The key phrase in the LFS book is "Unless the test
results are vastly different from those at the above URL, it is safe
to continue."
>
> The unexpected failure deviates from the build logs for 6.2 tracing
> the output leads to:
>
> ####################################################
> Running /sources/gcc-4.0.3/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
> FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
> ####################################################
My experience is that 'test for excess errors' is usually the
result of a failure to compile (and for this there is usually an
error message - perhaps the error is on stderr and you missed the
'2>&1' to capture it, or perhaps your case was different). But
again, I'm not inclined to worry about a _single_ failure just
because others haven't seen it. Perhaps, your host system is
unusual, or maybe the host kernel is the problem.
>
> _Pragma3.c contains:
>
> ####################################################
> /* { dg-do preprocess } */
>
> /* Pragma buffers have a NULL "inc" member, which we would dereference
> when getting a file's date and time.
>
> Based on PR 7526. 14 Aug 2002. */
>
> #define GCC_PRAGMA(x) _Pragma (#x)
> GCC_PRAGMA(GCC dependency "mi1c.h")
> ####################################################
>
> mi1c.h contains:
>
> ####################################################
> /* Redundant header include test with C comments at top. */
> # /* And a null directive at the top. */
>
> #ifndef CPP_MIC_H
> #define CPP_MIC_H
>
> int a;
>
> #endif
>
> # /* And at the end, too! */
> /* And at the end too! */
> ####################################################
>
> I'm not sure what this means, I checked the permissions and the
> files/directories are all owned by gcc. I'm not much of a c/c++
> programmer and I don't know if this is something I can live without or
> not.
>
> Thanks in advance.
The gcc bugzilla [ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7526
] shows the original problem was cpp0 dumping core. If that's the
case, the test presumably dumped core, so it would fail to compile.
That doesn't change my view that a single extra failure is almost
certainly not a big deal. Of course, if you build the system and
it then starts dumping core when it encounters _Pragma operations,
that will just prove I'm sometimes wrong ;-)
You've checked the ownership and permissions, so (as someone who
doesn't use the package management method), I think lfs-support
would have been the correct place for this.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
