On Wed, Sep 30, 2009 at 2:50 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > > William Stein wrote: >> On Wed, Sep 30, 2009 at 12:29 PM, Dr. David Kirkby >> <david.kir...@onetel.net> wrote: >>> http://sagetrac.org/sage_trac/ticket/6579 >>> >>> documents a problem which will occur if one tries to build Sage using >>> gcc on 't2', or any other Solaris box I have tried on. One has to >>> manually comment out lines 258, 259 and 428 of the file >>> $SAGE_HOME/local/include/pari/paripriv.h >>> >>> I personally don't know how to fix this issue. Nobody I'm aware of has >>> looked at it. So each time Sage is built on Solaris, one needs to >>> manually edit the file. >>> >>> What do we do about this? >> >> We have *exactly* the same problem with the Cygwin port. One >> possibility would be >> to put a #ifdef around those 3 lines in order to remove them. >> >> Note that I think this problem only appears when building the *Sage* >> library, not when >> building PARI. So we would pass -Dsomething to Cython so those lines don't >> get >> included when building the Sage library. What do you think? If this >> seems reasonable for >> you, I think I can easily implement it (since, again, it is needed for >> the Cygwin port). >> >> William > > I think that sounds reasonable, though without understanding the library > (which I don't), I have no idea of the implications. Someone said GAP > would be affected.
Huh?! Nobody said anything about GAP -- that just makes no sense. > I'd hate to see Solaris or Cygwin become second-rate versions of Sage. > (I often feel Mathematica on Solaris is not as good as the more popular > Linux or Windows versions. ) I would love to see Cygwin have some version of Sage at all (which it doesn't right now). > I'd suggest a few things that I feel would be useful and hopefully avoid > this. > > * You update http://sagetrac.org/sage_trac/ticket/6579 to say this > happens on Cygwin too. > > * Until the issue is resolved properly, that something should be added > to the banner to indicate what is basically a hack. > > * An environment variable will allow the hack to be enable or disabled > at compile time. > > Another option, and perhaps a better one, would be to comment out the 3 > lines on ALL platforms, then wait until there are some bug reports > traceable to this. If the hack could be disabled with a compile-time we > might have more hope of finding out the real cause. > > > If http://sagetrac.org/sage_trac/ticket/7040 were resolved, we might be > able to build the library with Sun's compiler. The absence or presence > of this issue with another compiler could be useful. > > Pari builds ok with Sun's compiler - it's the Sage library which does > not, as CC is not respected properly. > > Dave > > If you have $50 spare in your grants, perhaps offer $50 prize to anyone > that can find the *real* cause! That might drum up a bit more interest > in solving a problem on a platform which most people do not use! I don't think this is a good way to drive Sage development. It's been tried before and the experience was thoroughly unpleasant. And I do understand this paripriv.h thing more deeply than you guys might think... paripriv.h = "pari private". It's not meant to be #included by any programs outside of pari itself. However, because we dig into pari and use it as a library -- which is very invasive -- to build certain cython code we require certain prototypes from there. Commenting out those lines will have no impact on this. William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
