It seems I only sent my reply to Emmanuel. So briefly: - Andrew: can you please confirm that the latest tarball provided by Emmanuel is fixed? - if that's the case, I'll open a trac ticket to update the gf2x spkg provided by Sage and it should make its way into Sage 5.12 or 5.13.
Best, JP On Friday, October 4, 2013 6:41:19 PM UTC+2, Emmanuel Thomé wrote: > > could you pleae confirm that the fix I've committed to the gf2x main > branch fixes the issue you encounter ? This is a genuine bug which > deserves to be fixed, so: > - I care about whether my changes correct the issue. > - I don't mind creating a bugfix tarball if deemed useful. > > On the other hand, if you consider the gf2x-1.1 spkg as distributed in > sage-5.11 as something immutable you can't change, there's not much I > can do. Frankly, you'd be better off replacing the spkg with a really > fixed one... > > E. > > On Fri, Oct 4, 2013 at 5:55 PM, Robert Campbell > <rcam...@umbc.edu<javascript:>> > wrote: > > The bug appears to be something in gf2x's configure.ac file, but as I > know > > little about writing config scripts it's hard to give advice. > > > > In the meantime, here is a simple step-by-step for those who want > SAGE-5.11 > > but have an old pre-SSE2 machine (schools & cheapskates like me): > > > > 1) Confirm that your machine doesn't have SSE2 - look for the sse2 flag > in > > the /proc/cpuinfo file. > > 2) Edit the gf2x spkg file: > > a) copy sage-5.11/spkg/standard/gf2x-1.1.spkg to a working location > > b) tar -jxvf gf2x-1.1.spkg > > c) Edit gf2x-1.1/spkg-install: > > Edit line 38 to read ./configure --enable-sse2=no > > --prefix="$SAGE_LOCAL" > > d) tar -jcvf gf2x-1.1.spkg gf2x-1.1 > > e) move gf2x-1.1.spkg back to its original location in > > sage-5.11/spkg/standard/. > > 3) Compile SAGE as usual > > > > Most folks in this situation will not want to compile SAGE themselves > (it > > took me 37 hours on my 1.3 GHz Athlon) and it would be nice to have a > > pre-compiled version available. An easy solution would be a binary from > > before the bug was introduced (gf2x-1.1 and hence SAGE-5.11), but I > don't > > see that older binary versions are available from sagemath.org. > > > > Robert Campbell > > > > On Friday, September 20, 2013 9:01:13 AM UTC-4, Andrew Fiori wrote: > >> > >> This is likely a build error bug on all systems which do not support > SSE2 > >> but where building is done using the current version of gcc. It may > also > >> manifest as a runtime error on binary builds installed on systems which > do > >> not support SSE2 (but I have not tested that). > >> > >> I am submitting this here rather than to bug tracker for several > reasons: > >> - It is unlikely anyone cares enough to fix this properly upstream > >> (which is where the bug really is). > >> - The build error only effects building from source on systems that > are > >> out of date and will becoming even less common going forward. > >> > >> I am mentioning it at all, because it will help anyone who comes across > >> this error in the future. The same type of error may cause somewhat > >> confusing runtime errors in other packages (bug tracker searches > suggest > >> this type of issue has come up before in other packages). > >> > >> The bug: > >> The bug is somewhere in the gf2x build scripts > "src/config/acinclude.m4" > >> or "src/configure" somehow it decides whether or not the system > supports > >> sse2 (look around line 75 of acinclude.m4. It appears to do this by > checking > >> if gcc can compile something that uses sse2. It turns out that it > can... > >> even if the system you are on cannot. Consequently it tries to build > >> everything with sse2. This causes a problem when it tries to tune > itself > >> "src/src/tune-lowlevel.pl". Around line 70-78 it tries to run the > compiled > >> code. Most of these don't require sse2 really, and so work, some do > (mul3t, > >> mul3k, mul3k2) these fail, it then can't pick which one to use, and > >> terminates building. > >> If there are other places in sage where similar sse2 detection is > used, > >> but which are not executed at build time (most things are not), then > sage > >> will encounter unexpected runtime bugs when pieces of code that can > benefit > >> from sse2 are used. > >> > >> > >> The solution: > >> gf2x doesn't require sse2 to work. The easiest way to build it on a > >> system where the above bug is encountered is to modify: > >> spkg-install:38 to become: > >> ./configure --enable-sse2=no --prefix="$SAGE_LOCAL" > >> You don't really want to do this in the main branch though, as this > slows > >> things down for the 99+% of people who don't have an archaic system > they are > >> trying to run sage on. > >> A better solution is to add an if statement at this place and > environment > >> variable globally to disable sse2 when it doesn't exist. > >> Alternatively one could invest the time and figure out then fix gf2x > build > >> system. > >> > >> - Andrew > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "sage-devel" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/sage-devel/Cp1lDMzyCrU/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > sage-devel+...@googlegroups.com <javascript:>. > > To post to this group, send email to > > sage-...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
