On Mon, Aug 14, 2006 at 12:07:22AM -0700, Dan Nicholson wrote:
> On 8/13/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> >
> > Any other failures ? Any suggestions, apart from "don't run the
> >testsuites" ?
>
> The only thing I can suggest is to look in the *.out files. They
> contain the stdout streams from the tests. Of course, then you have to
> be able to decipher what glibc is up to and why it's failing... At
> least you might be able to get something more specific to google on.
>
Thanks for that, Dan - I'm more confused than ever! Went back to
the ppc64 system, using the temp system I'd prepared earlier (with a
broken bash, so c++-types-check still fails). Now I'm only seeing
ONE other failure beyond posix/annexc : in 32-bit,
elf/check-textrel.out still fails. So, the weirdness in the 64-bit
test that reported bash-3.1 not found has vanished (worrying - maybe
it is related to fixing bash) and the other failures have gone
(possibly, marginal timings).
But, elf-check-textrel.out looks ok - there are 223 messages saying
that segment 1 (or segment 3) is executable and writable, but no
other messages at all. The code (elf/check-textrel.c) has
printf ("%s: segment %zu is executable and writable\n",
fname, cnt);
#if !defined __sparc__ \
&& !defined __alpha__ \
&& (!defined __powerpc__ || defined __powerpc64__ || defined
HAVE_PPC_SECURE_PLT)
/* sparc, sparc64, alpha and powerpc32 (the last one only
* when using
-mbss-plt) are expected to have PF_X | PF_W segment
containing .plt
section, it is part of their ABI. It is bad security
wise, nevertheless
this test shouldn't fail because of this. */
return 1;
#endif
and then there are various other possible errors which each use a
printf to put the message to fname (stdout) before retrning 1, or an
'OK' and return 0. It seems that one of the errors is triggering
for each input file, because the 'OK' is never produced.
In the absence of any other error messages, it looks as if the
tests above are causing the 'executable and writable' message to be
followed by return 1. This I do not understand. If I compile with
-m32, __powerpc__ is defined and __powerpcc64__ is not defined.
(with -m64, both are defined). The included config.h for 32-bit has
#undef HAVE_PPC_SECURE_PLT -commented- with a note that it is needed
if the compiler defaults to -msecure-plt. Other than that, there
are no references to HAVE_PPC_SECURE_PLT and it doesn't seem to be
defined when I compile. So, I read the tests in 32bit as:
! __sparc__ && ! __alpha__ : ok so far
&& (! __powerpc__ || __powerpc64__ || HAVE_PPC_SECURE_PLT ) : all false
which would work happily.
I think I might go back to banging my head against a brick wall, it
hurts less ;)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
