OK, the problem is as follows. For very straightforward C programs, no problems occur on t2 because the compiler emits inline code for everything. However, once the program becomes too complicated for it to do this, it uses libgcc:
http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html The problem is, when the compiler compiles such a program, the linker does not know where to find libgcc on the machine. It needs to know that it is in: /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 However, this is not in /etc/ld.so.conf, which does not exist on Solaris machines, nor is it in LD_LIBRARY_PATH. Why it won't work with this in LD_LIBRARY_PATH_64 I do not know. But either way, this problem is not something we can work around in MPIR, that I know of. It's just that MPIR uses some very complex arithmetic expressions for which gcc is unable to emit inline assembly. Even writing a basic test case that exhibits this failure would be difficult. I've no idea what the solution to the problem is. Back to the sparc expert for this one! Bill. 2010/1/28 Bill Hart <goodwillh...@googlemail.com>: > 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
