Ticket #5628 (closed defect: fixed)
[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
Change History
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: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

