5.0.1 test failures on alphaev56-dec-osf4.0g (Tru64)

[Torbjorn Granlund]

"Daniel Richard G." <skunk at iSKUNK.ORG> writes:

  On Tue, 2010 Sep  7 12:46+0200, Torbjorn Granlund wrote:
  >
  > Incompatibilities in how to access memory with relocs are not
  > uncommon. But since this file is more than 10 years old, such
  > incompatibilities seem unlikely.
  
  Okay. Is there any further testing I could do that would help track down
  the problem? Some sort of sanity check, perhaps?
  
Please use gdb to see which exact instruction fails.

Is it a shared build or a static build that fails?  (Passing
--disable-shared to configure will make sure the build uses just static
linking, passing --disable-static will make sure it is shared.)

Please see which assembler is being used.  A command like "gcc -v foo.c"
will tell you that.  It is also possible that the assembly is behaving,
but that the linker is misbehaving.

It is possible for us to support the assembler since it is clearly can
handle lots of code spit out by the compilers.  We need to understand
what of our file it dislikes, and then what we could feed it instead to
make it happy.

By generating a little C code function and compile that to assembly, we
could figure out what to do.

Note that we might in the end decide to not work around this issue,
since osf4 is considered obsolete.  It might be wiser that you install a
better assembler, or install a current OS...

  Alternately, is there a way to disable assembly piecewise, so I don't
  have to use the slow C fallbacks for everything?
  
You could remove that file and so if that's enough.

-- 
Torbjörn