Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 679386 - dev-util/catalyst: Patches to fix a few items
Summary: dev-util/catalyst: Patches to fix a few items
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 434268
  Show dependency tree
 
Reported: 2019-03-04 06:50 UTC by Joshua Kinard
Modified: 2020-04-18 19:40 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Remove MIPS R10K subarch (catalyst-3.0.4-remove-r10k-bits.patch,1.90 KB, patch)
2019-03-04 06:50 UTC, Joshua Kinard
Details | Diff
Add missing stage3 override functions (catalyst-3.0.4-fix-stage3-overrides.patch,1.05 KB, patch)
2019-03-04 06:51 UTC, Joshua Kinard
Details | Diff
Add missing ASFLAGS override functions (catalyst-3.0.4-add-missing-asflags-overrides.patch,1.88 KB, patch)
2019-03-04 06:52 UTC, Joshua Kinard
Details | Diff
Keep mips4 and change R10K definitions into R5K (catalyst3-keep-mips4.diff,2.07 KB, patch)
2020-04-18 18:33 UTC, Joshua Kinard
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard gentoo-dev 2019-03-04 06:50:34 UTC
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.
Comment 1 Joshua Kinard gentoo-dev 2019-03-04 06:51:18 UTC
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).
Comment 2 Joshua Kinard gentoo-dev 2019-03-04 06:52:09 UTC
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.
Comment 3 Joshua Kinard gentoo-dev 2019-03-04 06:52:53 UTC
(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
Comment 4 Brian Dolbec (RETIRED) gentoo-dev 2019-03-04 07:53:06 UTC
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?
Comment 5 Joshua Kinard gentoo-dev 2019-03-04 08:44:58 UTC
(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.
Comment 6 Larry the Git Cow gentoo-dev 2020-04-14 18:29:50 UTC
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(-)
Comment 7 Joshua Kinard gentoo-dev 2020-04-18 18:31:34 UTC
(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.
Comment 8 Joshua Kinard gentoo-dev 2020-04-18 18:33:17 UTC
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.