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.
I am not installing MPIR on these machines, as I do not have root access on either. Thus whatever is in /usr/local/lib is not my responsibility. Libtool builds the MPIR library in a directory in the MPIR source tree, then links against that. This works on every other architecture I am aware of. > > 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. So maybe that has nothing to do with MPIR. > > 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). There are only two possibilities, core2 and penryn. If you tell me the family and model of the processor I'll check that it is selecting the correct one. > > 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. As far as I know that's impossible to change. The tests are run per source directory by autotools. All packages that use autotools do that. You could report this issue on the autotools list. > 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. > If you run make check a second time you will see all the tests without the compilation. Also, if any tests fail in any directory the whole process stops (assuming they even ran in the first place). Bill. -- 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
