So on t2 there is no /usr/local/lib/sparcv9, so that's a bit useless! Does this mean t2 is not capable of running 64 bit binaries?
2010/1/28 Dr. David Kirkby <david.kir...@onetel.net>: > 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. > > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
