One sensible solution would seem to be to set LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2, but this actually doesn't seem to work. I'm not sure why.
However it seems that one can just add /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it doesn't matter whether at the beginning or end) and this fixes the problems on t2. Shouldn't this be done globally for all users? Bill. 2010/1/28 Bill Hart <goodwillh...@googlemail.com>: > 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.
