Ticket #5628 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

[with patch; positive review] work arroud annoying false positive SSE4a sage-flags.txt issue

Reported by: was Owned by: was
Priority: blocker Milestone: sage-3.4.1
Component: distribution Keywords:
Cc: Work issues:
Report Upstream: Reviewers:
Authors: Merged in:
Dependencies: Stopgaps:

Description

On Sat, Mar 28, 2009 at 9:05 PM, Gonzalo Tornaria:
>
> I did an upgrade from 3.4 as follows:
>
> 1. sage -br main  ---> switch to main, which is CLEAN
> 2. sage -upgrade
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/sage-3.4.1.alpha0
> 3. once that was finished, I pulled  the new changes into my sage-brandt branch
> 4. applied the rebased 5520 + my tiny patch
> 5. sage -br brandt
>
> But now, "sage -br main" (which is now clean 3.4.1.alpha0) causes the
> same issue.
>
> Gonzalo

Just delete 
   local/lib/sage-flags.txt

Also, I've opened a blocker ticket about this, since everybody who upgrades will run into exactly the same problem.  

The problem is that the new version of the script that checks the flags doesn't see sse4_1 anymore (nothing in Sage specifically uses that), but it's still in your old sage-flags.txt file.  Two possible solutions:
   (1) delete sage-flags.txt as part of "sage -upgrade"
   (2) make it so sse4_1 is specifically ignored.

I like (1). 

Attachments

trac_5628-scripts.patch Download (754 bytes) - added by was 4 years ago.
trac_5628.patch Download (803 bytes) - added by mabshoff 4 years ago.

Change History

Changed 4 years ago by was

comment:1 Changed 4 years ago by was

  • Summary changed from a little sage-flags.txt issue to [with patch; needs review] a little sage-flags.txt issue

comment:2 Changed 4 years ago by tornaria

The issue with this patch is that the sage-flags.txt file will not be regenerated unless sage install directory changes (because write_flags_file() is only called from within install_moved().

Maybe the flags file should also be created from the check_processor_flags() function. But then, this only works if sage is run at least once after an upgrade.

Otherwise, doing sage -upgrade followed by sage -bdist ends up with a sage binary with no sage-flags.txt, defeating the purpose of the flags file.

comment:3 Changed 4 years ago by tornaria

I have an alternative fix:

diff -r 804879ae0134 sage-location
--- a/sage-location     Thu Mar 26 16:43:48 2009 -0700
+++ b/sage-location     Sat Mar 28 22:32:50 2009 -0700
@@ -77,7 +77,7 @@
     if not os.path.exists(flags_file): return
     # We check that the processor flags of the original build are a
     # subset of the new machine.  If not, we print a massive warning.
-    X = set(open(flags_file).read().split())
+    X = set(open(flags_file).read().split()).intersection(FLAGS)
     Y = set(get_flags_info().split())
     if not X.issubset(Y):
         print ""

This makes it so that only the flags listed in FLAGS are relevant for check_processor_flags(). Thus, after an upgrade, the flag sse4_1 will still be in the flags file, but it won't be required at runtime.

comment:4 Changed 4 years ago by mabshoff

I actually like Gonzalo's fix better than William's - not sure what to do about this yet.

Cheers,

Michael

comment:5 Changed 4 years ago by was

I'm fine with either version.

comment:6 Changed 4 years ago by mabshoff

  • Milestone changed from sage-3.4.2 to sage-3.4.1

This is a 3.4.1 blocker.

Cheers,

Michael

Changed 4 years ago by mabshoff

comment:7 Changed 4 years ago by mabshoff

  • Summary changed from [with patch; needs review] a little sage-flags.txt issue to [with patch; positive review] work arroud annoying false positive SSE4a sage-flags.txt issue

Positive review for trac_5628.patch.

Cheers,

Michael

comment:8 Changed 4 years ago by mabshoff

  • Status changed from new to closed
  • Resolution set to fixed

Merged in Sage 3.4.1.rc2.

Cheers,

Michael

Note: See TracTickets for help on using tickets.