SHA256
9
0
forked from pool/gcc15

main #3

Closed
adrianSuSE wants to merge 1 commits from adrianSuSE/gcc15:main into main
First-time contributor
No description provided.
adrianSuSE added 2 commits 2025-10-31 08:49:26 +01:00
Author
First-time contributor

I was able top build klipper firmware with this compiler as function test.

I was able top build klipper firmware with this compiler as function test.
adrianSuSE added 2 commits 2025-10-31 08:51:18 +01:00
Owner

Hmm, it's on purpose that we do not build the newlib crosses on SLES since that does not have newlib ... while it's building fine in devel:gcc and maybe even against Leap 16.0 we cannot do this.

Hmm, it's on purpose that we do not build the newlib crosses on SLES since that does not have newlib ... while it's building fine in devel:gcc and maybe even against Leap 16.0 we cannot do this.
rguenther closed this pull request 2025-10-31 13:16:27 +01:00
Author
First-time contributor

so gcc15 needs to be forked into packagehub project then?

so gcc15 needs to be forked into packagehub project then?
autogits-devel requested review from matz2 2025-10-31 13:47:40 +01:00
autogits-devel requested review from rguenther 2025-10-31 13:47:40 +01:00
Owner

we do not want to "fork" the SLE gcc15 into a SLE and a Leap one, no. Building the same sources again in opensuse context and picking the packages only generated there might work. Note the set of crosses is not the only difference between SLE and is_opensuse which is why "forking" would give you a quite inconsistent result.

we do not want to "fork" the SLE gcc15 into a SLE and a Leap one, no. Building the same sources again in opensuse context and picking the packages only generated there might work. Note the set of crosses is not the only difference between SLE and is_opensuse which is why "forking" would give you a quite inconsistent result.
Author
First-time contributor

right, but wouldn't it be easier then to build this one additional package then also in slfo-1.2? we would not put it on any maintained medium like SLES-16.0.

Otherwise we would need a complete new source to build the one cross compiler to get it into PackageHub or is there another way?

right, but wouldn't it be easier then to build this one additional package then also in slfo-1.2? we would not put it on any maintained medium like SLES-16.0. Otherwise we would need a complete new source to build the one cross compiler to get it into PackageHub or is there another way?
Owner

Looks like the autogits bot goes wild on this one, re-starting test builds all the time? What can I do to "wipe" this PR from its eyes?

Looks like the autogits bot goes wild on this one, re-starting test builds all the time? What can I do to "wipe" this PR from its eyes?

Pull request closed

Sign in to join this conversation.
No Reviewers
No Label
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gcc/gcc15#3
No description provided.