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.
