2010/1/28 Dr. David Kirkby <david.kir...@onetel.net>: > 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.
And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests. Is this a standard directory that libtool should know to look in? > > $ 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. It's because LD_LIBRARY_PATH is set incorrectly on t2. > > You said it did not build on UltraSPARC II. I suspect you will find it will > not build on any SPARC system. It does build in the UltraSPARC II. I was only looking at the output of the C++ tests, and these had always failed on that machine, but this is due to a library which is completely missing from the machine. I can't change that as I do not have root access. It has failed for every version of MPIR. > >> 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. That's probably true, if the sparcv9 directory is in a standard place. > 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. It works fine on SkyNet/mark which is a Solaris SPARC machine. Of course the LD_LIBRARY_PATH needs to be set correctly there too. > > 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 MPIR can only use names for processors corresponding to assembly language we've actually written. We've written no special assembly language for these particular Xeons, so it uses the best code we have available for this processor, which is core2. You are welcome to contribute better assembly code for this machine if you want. :-) > - 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. > > 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.
