OK, on gcc54 only the C++ tests fail. But they always did. There is actually a library missing from the machine which is needed to run binaries compiled by the C++ compiler. All the C test binaries pass on gcc54.
So the only issue is actually on t2. Basically I think there is a whole pile of wrong stuff in LD_LIBRARY_PATH. By default when I log into that machine it is set to: /usr/local/gcc-4.2.4-sun-linker/lib:/usr/local/lib So not much wonder 64 bit binaries don't work. Basically my guess is this is not an MPIR problem, but a problem with the way the machine is set up. But I could easily turn out to be wrong about this. Bill. 2010/1/28 Bill Hart <goodwillh...@googlemail.com>: > 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. >> > -- 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
