Jean-Pierre, [please forward to sage-devel, since I'm not subscribed, thus my mail will be rejected]
thank you for forwarding us that message: > Date: Fri, 20 Sep 2013 11:36:26 -0700 (PDT) > From: Jean-Pierre Flori <jpfl...@gmail.com> > Cc: Zimmermann Paul <paul.zimmerm...@loria.fr> > > [1:multipart/alternative Hide] > [1/1:text/plain Hide] > Hey, > > I think you should report this to the gf2x dev as well... you never know. > I've CC'ed Paul Zimmermann in case he cares. yes we care! > Best, > JP > > On Friday, September 20, 2013 3:01:13 PM UTC+2, 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 I'm puzzled because in the version of GF2X shipped with Sage 5.11, src/config/acinclude.m4 defines SSE2_EXAMPLE on lines 75-79, then it is used in AC_RUN_IFELSE (not AC_COMPILE_IFELSE) on lines 90 and 94. Thus I would say it is a bug in gcc. Please can you send us the corresponding config.log file from gf2x? Best regards, Paul -- 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.
