On t2 all the tests fail, complaining of the same issue. If I actually go into the tests directory and run one of the test scripts directly, here is what it does:
./t-modlinv ld.so.1: t-modlinv: fatal: libmpir.so.8: open failed: No such file or directory Killed So let's see what the script does: program='t-modlinv' progdir="$thisdir/.libs" if test -f "$progdir/$program"; then # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/home/wbhart/mpir-1.3.0/.libs:$LD_LIBRARY_PATH" # Some systems cannot cope with colon-terminated LD_LIBRARY_PATH # The second colon is a workaround for a bug in BeOS R4 sed LD_LIBRARY_PATH=`$echo "X$LD_LIBRARY_PATH" | $Xsed -e 's/::*$//'` export LD_LIBRARY_PATH In fact if I do: ldd /home/wbhart/mpir-1.3.0/tests/.libs/t-modlinv libmpir.so.8 => (file not found) libc.so.1 => /usr/lib/sparcv9//libc.so.1 libm.so.2 => /usr/lib/sparcv9//libm.so.2 /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1 So it can't find libmpir.so.8. But I don't see why. echo $LD_LIBRARY_PATH /usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs But: wbh...@t2:~/mpir-1.3.0/tests$ ls ../.libs .... compat.o libmpir.so.8 randbui.o rands.o dummy.o libmpir.so.8.0.0 randclr.o randsd.o .... So it's there. Do sparc machines just ignore LD_LIBRARY_PATH or something? Bill. 2010/1/28 Bill Hart <goodwillh...@googlemail.com>: > 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. > -- 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.