Minh Nguyen wrote: > Hi David, Hi Minh
> On Fri, Jul 17, 2009 at 12:04 PM, Minh Nguyen<nguyenmi...@gmail.com> wrote: >> On Fri, Jul 17, 2009 at 12:01 PM, Dr. David >> Kirkby<david.kir...@onetel.net> wrote: >> >> <SNIP> >> >>> I forgot. Try: >>> >>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/mpfr/mpfr-2.4.1p0.spkg >>> >>> it should make no difference whatsoever, as the version of gcc in use >>> should be ok without the patch, but you can at least try it. >> OK. I'll now try >> >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/mpfr/mpfr-2.4.1p0.spkg >> >> and >> >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori/polybori-0.5rc.p9.spkg > > A fresh build of Sage 4.1 from scratch with the following MPFR spkg: > > http://sage.math.washington.edu/home/mvngu/patch/mpfr-2.4.1.p0.spkg > > I used that spkg of MPFR because the one at > > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/mpfr/mpfr-2.4.1p0.spkg > > doesn't conform to the naming convention of spkg's. The name of the > spkg should be "mpfr-2.4.1.p0.spkg", not "mpfr-2.4.1p0.spkg"; notice > the period in the former between "1" and "p0". I checked in all > changes in mpfr-2.4.1.p0.spkg in your name. All of the 148 tests > passed and mpfr-2.4.1.p0.spkg built OK. Thank you. I will remember the extra period next time. > The problem now is that PolyBori still died with the same error > message. I took your spkg at > > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori/polybori-0.5rc.p9.spkg > > checked in all changes in your name and uploaded the updated one at > > http://sage.math.washington.edu/home/mvngu/patch/polybori-0.5rc.p9.spkg > > To make sure that all global environment variables that you've set > take effect, I logged out of t2, then logged in again. And started a > fresh build from there. PolyBori died with the same error message. > Maybe I didn't follow your instructions correctly. Anyway, the > compressed full log is up at > > http://sage.math.washington.edu/home/mvngu/patch/solaris-polybori-install.log.bz2 > I get that too, although it builds in my machine at home with the patch. On my Blade 2000 I get: scons: done building targets. Done installing PolyBoRi. Removing dynamic libraries... Done removing dynamic libraries. real 17m35.011s user 15m44.474s sys 1m34.400s Successfully installed polybori-0.5rc.p9 At first I thought the reason why polybori was not building on 't2' was that gcc 4.2.4 would not compile the code. That may still be so, as the error message you show indicates gcc is finding syntax errors. But what I notice is that the Sun C++ compiler 'CC' is still called a couple of times in your log. ---------------------------------------------------------------- /opt/SUNWspro/bin/CC -o Cudd/obj/so_cuddObj.o -c -O3 -Wno-long-long -Wreturn-type -g -fPIC -ftemplate-depth-100 -g -fPIC -KPIC -O3 -Wno-long-long -Wreturn-type -g -fPIC -fPIC -DNDEBUG -DPACKED -DHAVE_M4RI -DHAVE_IEEE_754 -DBSD -I/scratch/mvngu/sage-4.1/spkg/build/polybori-0.5rc.p9/src/boost_1_34_1.cropped -I/scratch/mvngu/sage-4.1/local/include/python2.6 -Ipolybori/include -ICudd/obj -ICudd/util -ICudd/cudd -ICudd/mtr -ICudd/st -ICudd/epd Cudd/obj/cuddObj.cc CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wreturn-type passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise ----------------------------------------------------------------- I thought removing the links from /opt/SUNWspro/bin to /usr/bin on 't2' would be sufficient to fool polybori into thinking Sun's compiler suite are not installed. Alexander Dreyer said polybori get's the variables from SCons, so I decided to look at SCons very briefly. In the file: scons-1.2.0/src/CHANGES.txt one reads... --------------- From Jean Brouwers: - Add /opt/SUNWspro/bin to the default execution PATH on Solaris. --------------- So it appears that SCons is programmed to look in /opt/SUNWspro/bin. That I don't have a problem with, but it should not be mandatory to use a compiler that is there. I could probably get polybori to build with one of two hacks on 't2' 1) Force /opt/SUNWspro to no longer exist. $ su # mv /opt/SUNWspro /opt/hdden-from-polybori-SUNwspro 2) Create a patch for scons, so it avoids looking in /opt/SUNWspro/bin So in summary * The patch I have, which includes the linker patch, will allow polybori to build on my Sun at home with gcc 4.4.0 which does not have the Sun compiler suite installed. That might be an argument for including the patch, if it looks otherwise ok. (Without changing the linker flags, as that does, polybori will not build on my home machine). * PolyBoRi uses the variables from SCons. I've no idea what actually causes the problem, but between them, they get in a real mess using two different compilers to compile C++ programs. * SCons is programmed to look into /opt/SUNWspro/bin for a compiler so finds 'CC' which is no doubt why polybori uses it. I've stuck something on http://scons.tigris.org/ds/viewForumSummary.do?dsForumId=1272 asking for some scons help, but it has not been approved by the moderator yet. Certainly the quickest solution is probably (untested) $ rm sage-4.1/spkg/installed/scons-1.2.0 $ su # mv /opt/SUNWspro /opt/hdden-from-polybori-SUNwspro But a better one would be to hack scons. Whatever way you look at this, it is a bit messy. Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
