On Mon, Aug 5, 2019 at 3:49 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Fri, 2019-08-02 at 19:13 +0200, Björn 'besser82' Esser wrote: > > Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco: > > > The upstream KiCAD project has requested that I remove > > > GLIBCXX_ASSERTIONS from the Fedora package, as described here: > > > https://bugs.launchpad.net/kicad/+bug/1838448 > > > > > > What is the best way to do that? I can add "%undefine > > > _hardened_build" (which I am testing now) but I think that will remove > > > other hardening features that I might want to leave enabled. > > > > > > Steve > > > > Simply add this to your spec file: > > > > # Upstream recommends to turn off _GLIBCXX_ASSERTIONS. > > # See: $UPSTREAM_BUG > > %global optflags %optflags -U_GLIBCXX_ASSERTIONS > > Am I the only one worried of seeing way too many people jumping on and > telling how to suppress these hardening features without a word of > cautiousness ? > > I feel like we should scan all spec files for this kind of stuff and > raise bugs if we find more than a handful of packages with this kind of > "workarounds" ... > Not many people are equipped to figure these out, and usually when these new flags are introduced, they come with no help and no information from the people introducing them. The last time I had to deal with this, I didn't even know this was the culprit initially, and I was stubborn and got upstream to help fix the issue. Koschei logs of dependency shifts with successes and failures helped me pinpoint the flaw. My experience with these issues is why I've never proposed increasing our default hardening. It's far too difficult to debug and the compiler people are unable or unwilling to help in most circumstances. Thankfully with *my* packages, I've gotten rid of most of filter-outs. But my D language packages require me to filter out quite a bit since our flags are enforced regardless of compiler, and currently all D software uses LDC, not GDC. We should probably fix that, but it's not the only language that forces us to deal with the "problem child" that is LLVM and the Clang stack. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
