Ah, got it. LD_LIBRARY_PATH_64 needs to also contain /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not specified at all, i.e. left blank, the linker uses whatever is in LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively, which means that *all* 64 bit library paths must be in LD_LIBRARY_PATH_64.
So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to be set globally for users *and* we'd need libtool to recognise that it needs to set LD_LIBRARY_PATH_64. Unfortunately libtool doesn't do this automatically. So this is seems to be a bug in the version of libtool we use. Another solution is to set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually works because the substitution is done live by the shell. In other words, if LD_LIBRARY_PATH_64 is set to /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all users of t2 globally, I believe MPIR will work just fine on that machine. Bill. 2010/1/29 Bill Hart <goodwillh...@googlemail.com>: > 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
