2012/5/4 Jerry James <loganjerry(a)gmail.com>:
On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade
>> /usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning
>> somebody nasty previously included <stdint.h> without
>> __STDC_LIMIT_MACROS :)
> This warning is all over the place, but so far, with the attached
> linbox-integer.patch on top of an installed system it does not
> fail earlier. But should get __STDC_LIMIT_MACROS defined
> before the first c++ code includes stdint.h ...
Right, I had to do that with m4rie also.
>> sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a
>> sage/libs/singular/singular.cpp: In function
Also an issue with m4rie. The problem is that there is now a
namespace involved, so you have to change all instances of GFqDom to
Yes, that was what I did, plus a few other Givaro:: added to the cython
sources in sage-fedora-prepare.patch.
> The attached sage-fedora-prepare.patch is another work in
> patch, that should be helpful to give an idea of what needs to be patched
> to build with newer linbox, sytem cudd, m4ri, m4rie, etc.
Okay, I'll look through it over the weekend. If you have parts that
you think are ready to go, the best thing to do is file a bug. That
way the patches won't get lost or forgotten.
Right now I will prefer to avoid proposing incomplete patches over
incomplete patches; I already submitted two patches to the sagemath
trac, but specified that they were only to give an idea of the issue,
and a call for feedback...
> Well, for singular, at least for now I think it is better to use
> version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora)
> appears to be going to require quite some work ...
Okay, we can pursue that path.
I am going to also give up in attempting to get sage-4.8 working, and
work on sage-5.0-rc0, at least it already uses polybori-0.8.1, what makes
life easier for me :-) But I am afraid it may not be easy to get all patches
integrated, because too many components will need to be updated
at once. But IMHO it is sage that is not playing so nice with upstream,
letting several components versions rot, and making things harder for
anybody willing to get sagemath working with system packages in a
Incidentally, looking at the latest Singular release, I see that it
can use flint if it is available. We have flint 1.6, which I kept
deliberately because Sage's flint package is at 1.5.0. However,
Singular wants flint 2.3! What should we do there? Is there a part
of sage that really needs the older flint version, or should I upgrade
it for Singular?
I really hope flint 2.3 is api compatible with flint 1.5.0, but did not
look at details so far.
Well, in Mandriva, unless it was an already a system package,
or maintained by somebody else, I always packaged the version
required by sagemath, this way things are easier to handle. And
still took me quite some time to have a usable package after
getting all components working together. But I plan to submit
a singular package for review shortly, unless you want to beat
me to that, then, I suggest following the pattern of the Mandriva
package to avoid too much problems with missing headers,
as well as the sagemath patches:
scitech mailing list