Created attachment 567718 [details, diff] Remove MIPS R10K subarch Attaching a few patches to fix some things in dev-util/catalyst-3.0.x: - catalyst-3.0.4-remove-r10k-bits.patch Removes the MIPS R10K subarch definitions, as they are no longer needed. A few years ago, gcc-upstream decided to make -march=r10000 the default for the MIPS-IV ISA, thus building with a "mips4" subarch is the same now as using the R10K subarchs.
Created attachment 567720 [details, diff] Add missing stage3 override functions - catalyst-3.0.4-fix-stage3-overrides.oatch Adds the missing *_override functions in catalyst/targets/stage3.py. As noted by the XXX comments in the stage1/stage2 target modules, these may be redundant. However, until the class hierarchy issue in catalyst is sorted out, that would permit the versions in stagebase.py to cover all the stage-specific modules, we need these overrides in place to avoid issues in stage3. This is a blocker for Bug #434628 (which I think is reporting this very issue).
Created attachment 567722 [details, diff] Add missing ASFLAGS override functions - catalyst-3.0.4-add-missing-asflags-overrides.patch Adds the missing "asflag_override" functions in catalyst/targets/stage{1,2,3}.py, which is needed to properly support defining specific ASFLAGS for each stage build. Partial support for defining ASFLAGS already exists, but will not work without these missing overrides as a short-term fix until the class hierarchy mess is sorted.
(In reply to Joshua Kinard from comment #1) > Created attachment 567720 [details, diff] [details, diff] > Add missing stage3 override functions > > - catalyst-3.0.4-fix-stage3-overrides.oatch > Adds the missing *_override functions in catalyst/targets/stage3.py. As > noted by the XXX comments in the stage1/stage2 target modules, these may be > redundant. However, until the class hierarchy issue in catalyst is sorted > out, that would permit the versions in stagebase.py to cover all the > stage-specific modules, we need these overrides in place to avoid issues in > stage3. This is a blocker for Bug #434628 (which I think is reporting this > very issue). Typo, I meant Bug #434268
quote: "... until the class hierarchy mess is sorted." What do you mean by that? Rather than adding the same override functions to each stage, why not just merge them into the stagebase functions to use either the make.conf or spec file supplied override setting? Are these overrides bad for any other target stages?
(In reply to Brian Dolbec from comment #4) > quote: > > "... until the class hierarchy mess is sorted." > > What do you mean by that? > > > Rather than adding the same override functions to each stage, why not just > merge them into the stagebase functions to use either the make.conf or spec > file supplied override setting? Are these overrides bad for any other > target stages? My assumption is the way catalyst2 did things is still not sorted out, given the XXX comment(s) in stage1/stage2 target modules. The preferred outcome would be to have the override functions in stagebase.py be the sole copies and reduce code duplication. But the comment indicates the overrides are still needed in the stage target modules. As such, my patches are basically just ports of what I have been using in catalyst-2.0.18-r4 for the last two years. And these changes don't add any specific ovverides themselves. They enable overrides to be set in a spec file and carried into the chroot's make.conf. Without them, ASFLAGS is completely ignored, and stage3 won't honor CHOST, which *does* cause problems on mips, as well as ignoring CFLAGS and other variables, which further breaks things. I'm not looking to try to rewrite the logic right now (tempting, however), due to lack of time. I've been using catalyst2 for the last few stage run attempts since ~2017, and got most of the bugs in the mips stuff sorted out (I think). So now to move to catalyst3 to make sure that works. Still have to hack out the asciidoc stuff due to a python2.7/python3.7 conflict (blame dev-libs/glib-utils), but that patch is local to my setup.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=39e28f75d0308b0cd1f0d41457379510d2c322c4 commit 39e28f75d0308b0cd1f0d41457379510d2c322c4 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-04-13 04:00:48 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-04-14 18:29:14 +0000 catalyst/arch: Add "r5k" to mips4 configurations I mistakenly thought -march=mips4 was synonymous with -march=r5k, but it actually meant r8k until 2015 when it changed to r10k. Rather than let others be confused (by removing the r10k configuration) just change the mips4 configs to r5k. Bug: https://bugs.gentoo.org/679386 Signed-off-by: Matt Turner <mattst88@gentoo.org> catalyst/arch/mips.py | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-)
(In reply to Larry the Git Cow from comment #6) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/proj/catalyst.git/commit/ > ?id=39e28f75d0308b0cd1f0d41457379510d2c322c4 > > commit 39e28f75d0308b0cd1f0d41457379510d2c322c4 > Author: Matt Turner <mattst88@gentoo.org> > AuthorDate: 2020-04-13 04:00:48 +0000 > Commit: Matt Turner <mattst88@gentoo.org> > CommitDate: 2020-04-14 18:29:14 +0000 > > catalyst/arch: Add "r5k" to mips4 configurations > > I mistakenly thought -march=mips4 was synonymous with -march=r5k, but it > actually meant r8k until 2015 when it changed to r10k. > > Rather than let others be confused (by removing the r10k configuration) > just change the mips4 configs to r5k. > > Bug: https://bugs.gentoo.org/679386 > Signed-off-by: Matt Turner <mattst88@gentoo.org> > > catalyst/arch/mips.py | 48 ++++++++++++++++++++++++------------------------ > 1 file changed, 24 insertions(+), 24 deletions(-) I kinda disagree with this change. I think there needs to be a target for plain "mips4", like there is for mips2 and mips3. We can add documentation somewhere to annotate that this sets -march=r10000 in gcc. Separate targets can be added for r5k, mainly by changing the older r10k targets into r5k. FWIW, I have tested a mips4-vanilla stage on my RM7K O2 with no ill effects, so the -march/-mtune changes should not affect R5K systems, as those two CPUs are similar to each other. Arguably, we should have an RM7K target, but the only SGI that could build that is an RM7K O2, which are both incredibly rare and incredibly slow.
Created attachment 633638 [details, diff] Keep mips4 and change R10K definitions into R5K Proposed patch edits the TOML definitions to keep a mips4 target around and convert the old R10K definitions into R5K.