Bill Hart wrote:
Hi all,
it is with pleasure that we (finally) officially release MPIR 1.3.0.
It is available at our website http://www.mpir.org/
Please note the following important things:
* I have been unable to get any tests to pass on ultrasparc2 machines,
I've just tried on an UltraSPARC III+, and no tests pass. The problem is quite
easy to see, though don't ask me how you solve it, as I don't know how to use
'libtool'.
Assuming gcc is installed under /usr/local (for simplicity), then the object
files are built 64-bit, but then a message similar to this is shown:
ld.so.1: t-hightomask: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
ELFCLASS32
/bin/bash: line 1: 22883 Killed ${dir}$tst
The problem is that 64-bit libraries should never be in /usr/local/lib. Instead
they should be in /usr/local/lib/sparcv9.
If we run 'ldd' on some files in /usr/lib, we see they are all 32-bit.
$ file /usr/lib/*
/usr/lib/libsldap.so: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically
linked, not stripped, no debugging information available
/usr/lib/libsldap.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically
linked, not stripped, no debugging information available
But if we do so on /usr/lib/sparcv9, then we see they are 64-bit.
$ file /usr/lib/sparcv9/*
/usr/lib/sparcv9/libST.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
dynamically linked, not stripped
/usr/lib/sparcv9/libST.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
dynamically linked, not stripped
/usr/lib/sparcv9/libUil.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
dynamically linked, not stripped, no debugging information available
So what is happening is that the 64-bit objects are trying to link with
libraries in a directory where the 32-bit libraries should be, and not where the
64-bit libraries should be. That will certainly fail.
I've just tried on a Sun Ultra 27 Xeon, and all tests pass, though I think the
processor being chosen is not optimal. It is picking 'core2' but I think there
is a better choice for the Xeon. (I forget what it is).
It would be helpful if all the tests were run together. It is a bit confusing
when 9 tests are run, then some more tests are compiled. Then some more tests
are run, then some more bits compiled. So one has to scroll up the screen, and
check that each set of tests have been successful. It would be good if all the
tests were first compiled, then all run together.
Dave
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
