On 12/4/19 6:27 PM, Jeff Law wrote:
On 12/4/19 8:24 AM, Wilco Dijkstra wrote:
Hi Jeff,
I've noticed quite significant package failures caused by the revision.
Would you please consider documenting this change in porting_to.html
(and in changes.html) for GCC 10 release?
I'm not in the office right now, but figured I'd chime in. I'd estimate
400-500 packages are failing in Fedora because of this change. I'll
have a hard number Monday.
It's significant enough that I'm not sure how we're going to get them
all fixed.
So what normally happens with the numerous new warnings/errors in GCC
releases? I suppose that could cause package failures too. Would it be feasible
to override the options for any failing packages?
Usually we're talking about a few dozen packages that are tripped by any
particular issue. The -fno-common issue is a full order of magnitude
larger. My builds show ~450 failures due to this issue.
We're investigating different approaches that don't just involve
reverting the patch or reverting for Fedora. Those just kick the can
down the road with no real progress and we're in the same position next
year.
The approach that seems most feasible would be to have an opt-out
mechanism. That would keep -fno-common as the default but provide a
mechanism for a package to opt-out.
Hello.
I'm going to discuss an approach that will be selected for openSUSE
distribution.
Of the ~450 packages affected I'd estimate that even with the opt-out
mechanism we're still going to have to fix ~100 packages immediately
because they don't honor the flags injection mechanisms which the
opt-out approach relies upon.
Fortunately, we switch at openSUSE to use -fpie by default and our packages
honor the flags ;)
I'm going to do some testing
today/tomorrow to see how many affected packages don't honor the flags
injection mechanisms we use.
If indeed it's ~100 packages that don't honor the flags injection, then
we're looking at adding 350 markers to opt-out plus ~100 real
fixes/workarounds. That's still a lot of mindless work, but probably in
the realm of possible.
I would like to mention here that key work is to report and explain that
to upstream. Only that will help for the future to reduce number of packages
that will need the -fcommon option. That's the biggest effort in my opinion.
I will highlight that having the tester has proven hugely valuable here.
If we'd found out about this later in the process we'd probably be
looking seriously at reversion.
Fully agree here.
Martin
jeff
