On 7 Mai, 17:47, William Stein <wst...@gmail.com> wrote: > On Fri, May 7, 2010 at 8:31 AM, Nathan O'Treally <not.rea...@online.de> wrote: > >> > 2. The port of Sage to GCC-4.5.0 is complete. All known issues have > >> > been fixed. > > > I hope work-arounds related to 4.5.0 bugs get out again once they've > > been fixed in 4.5.1 or 4.5.2. > > There is exactly one such workaround in sage itself, I think, where > with -O2 and an assert, the compiler crashes, but with -O0 it doesn't > -- we removed the assert in conjunction with the author of the spkg > (=gfan). I think *all* of the many other issues in porting Sage to > work with GCC-4.5.0 were bugs in components of Sage that were > revealed through GCC-4.5.0's improved adherence to standards.
If so, OK. I haven't yet looked at all 4.5.0-related (or better - triggered) patches. I mostly only noticed your and Willem's 48?-hour-"overnight"- efforts... :-) > > (I wouldn't consider gcc x.y.0 releases "stable"; even x.y.1 C/C++ > > releases used to have major bugs that made them "unusable" - > > obviously depending on the application/features the code uses.) > > If we didn't build Sage with GCC-4.5.0, then the bug I mentioned above > might not have got reported at all. There is a reason GCC-4.5.1 will > hopefully have less bugs building real world code -- because people > like us did the work to build with GCC-4.5.0 and report bugs. I didn't say one shouldn't try early releases (actually, I said the opposite). But to me there's a difference between test builds and integrating patches (or work-arounds) cut to some (software I consider a) "pre- release". I know you like "release often, release early", and I know Sage is different to other software projects, so enclose the above in flame/ ignore tags at your taste. ;-) Your agreement with skynet of course is something else (though I would perhaps clarify what *they* consider "latest [stable] release" if necessary). > > I was also thinking of sorting out which packages or parts of Sage > > *really* rely on gcc, i.e. trying to build parts with other (C/C++) > > compilers. The unintentional fact that Sage currently requires gcc (or > > other gnuish tools) shouldn't encourage people to use gnuisms in > > general. By building with other tool chains, potential future problems > > (with gcc) might show up as well. > > We're just part of a much bigger community. I can't tell the GAP, > Singular, Pari, etc., developers which compilers to support. > However, I think they do appreciate feedback about issues with other > compilers, and patches. Yes. But I'm not aware of a list which spkgs (including the Sage library) currently require what. (This is most probably documented upstream, or can be deduced from configure-scripts, but a Sage compilation wouldn't be bad, especially if Sage does not include the latest upstream release of some package.) (It may e.g. make sense to build individual packages with different compilers on specific platforms if they are available/the user wants to.) -Leif -- 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
