I tried building a 32 bit binary with this in the LD_LIBRARY_PATH and everything works fine. Again it doesn't matter which order the directories are specified in LD_LIBRARY_PATH. Solaris must just figure out which libraries to use based on their ELF type and whether -m32 or -m64 is passed to the compiler.
Bill. On Jan 28, 11:46 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > 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. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
