Bill Hart wrote:
2010/1/28 Dr. David Kirkby <david.kir...@onetel.net>:
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.
But I was using a compiler installed in /usr/local. When that compiler was
installed, by default it uses
/usr/local/man - man pages
/usr/local/bin - binaries
/usr/local/lib - 32-bit libraries
/usr/local/lib/sparcv9 - 64-bit libraries.
To answer your other question about 't2'. Agreed it has no
/usr/local/lib/sparcv9, but gcc is not installed in /usr/local.
Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/
So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib and
the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9.
$ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9
libgcc_s.so libgomp.so.1 libssp.so.0.0.0
libgcc_s.so.1 libgomp.so.1.0.0 libstdc++.a
libgfortran.a libgomp.spec libstdc++.la
libgfortran.la libiberty.a libstdc++.so
libgfortran.so libssp.a libstdc++.so.6
libgfortran.so.3 libssp.la libstdc++.so.6.0.12
libgfortran.so.3.0.0 libssp_nonshared.a libsupc++.a
libgomp.a libssp_nonshared.la libsupc++.la
libgomp.la libssp.so
libgomp.so libssp.so.0
> 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.
libtool picks the right libraries under many programs in Solaris. I would
suggest there is some error in how libtool is being used. I would ask on the
libtool mailing list, and see if they can help you.
Most platforms do not support both 32 and 64-bit builds, so most platforms do
not have to have different directories for 32 and 64-bit libraries.
The compiler should know to pick up the correct library. I've no idea why it is
not in this case, but I can assure you there are many programs I've built as
64-bit under Solaris on SPARC which use libtool.
You said it did not build on UltraSPARC II. I suspect you will find it will not
build on any SPARC system.
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.
Loads of packages build in Sage with libtool, and do not have this problem.
Perhaps there is some mis-configuration of libtool. If the compiler is called
with the -m64 option, and asked to link against one of its libraries, it should
automatically know to look in the sparcv9 subdirectory. However, no doubt a
mis-configuration of libtool would cause it to look elsewhere.
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 think you will find it is. Otherwise this problem would be seen whenever
64-bit programs are installed on Solaris SPARC.
You may not have come across this problem on other platforms, as most other
platforms do not support the use of both 32 and 64-bit objects.
I would add the same arises with Solaris on x86/x64 processors. But in that
case, the libraries are stored under 'amd64' rather than the 'sparcv9'
subdirectories. Why this is working on Solaris x86/x64 (i.e. my Intel Xeon) and
not on any SPARC I've tried, is something best asked on the autolib mailing list.
Ralf Wildenhues, Ralf dott Wildenhues att gmx.de
is one person I know who is a libtool developer, who also has an account on
't2'. I suspect he could help you.
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.
I'm using an Intel W3580 - 3.33 GHz Quad core Xeon.
http://ark.intel.com/Product.aspx?id=39723
I've seen other packages use something different to both core2 and penryn, and
if I recall correctly, the name was some sort of code name used on Xeons - I
can't recall off-hand.
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.
Fair enough. I know mpfr runs all the tests at once, but perhaps they build
everything in one directory. I don't know.
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.
OK, thank you for that.
I hope you can resolve this issue, as it would be ashame if mpir stopped working
on SPARC systems.
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.
