That was my first inclination "just install it", but then I read the
warning and decided to look at stuff. After looking, I actually
thought that it was handling comments improperly. I rebuilt it without
'unexpected errors' and I was just about to post a nevermind, but
thanks for looking at it. Checking the package site for open bugs was
definitely something I hadn't thought of.
As far as which list to post to, I figured I had about a 50% chance of
getting that right cause I had no clue what the problem was. :)
On 1/7/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
> 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
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
