3 ms·

We've done the work for Fedora now. There was a long thread on the subject at the beginning of the effort which is interesting: https://lists.fedoraproject.org

by rwmj 3y ago

We've done the work for Fedora now. There was a long thread on the subject at the beginning of the effort which is interesting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CJXKTLXJUPZ4F2C2VQOTNMEA5JAUPMBD/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...

veltas 3y ago
As someone who doesn't know a lot about distro work, what exactly did you have to do for Fedora? Fix packages that weren't building anymore with this change?
- cozzyd 3y ago
  As I understand it, the main problem is autoconf-generated stuff with old versions of autoconf.
  - pests 3y ago
    Yep, errors result in autoconf checks failing leading to features being disabled, symbols being removed and more all while the build still succeeds successfully.
    - rwmj 3y ago
      This was the danger, but I think Florian did something where he compared autoconf output before and after the change and identified problems that way.
- fweimer 3y ago
  Packages fail to build after a while all the time. The maintainer fixes them (preferably using an upstream patch), and we move on. The issue with this set of compiler changes was that a lot of software builds successfully, but the new build suddenly has expected features missing. This happened with the previous attempt: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AL3PXQ3HX26PCF5PYDZ5RU7VJZSBZEPQ/#7I7DBPE6T52TH4XA5SN2DI2HFPAVBYHT https://lists.fedoraproject.org/archives/list/devel@lists.fe... That happened in 2016. In 2019, we undertook another attempt, this time with config.log/config.h diffing, but for various reasons stopped after fixing a few dozen packages, so it never went to the Fedora/upstream proposal stage. After Xcode and Clang the changed the defaults, it was somewhat easier to convince people that we should get Fedora & upstreams ready for a future GCC change. It also helped that Gentoo has been pushing fixes for Clang compatibility upstream for a while (https://bugs.gentoo.org/408963 https://bugs.gentoo.org/408963, with a broader scope in https://bugs.gentoo.org/870412 https://bugs.gentoo.org/870412).

by rwmj 3y ago

veltas 3y ago

As someone who doesn't know a lot about distro work, what exactly did you have to do for Fedora? Fix packages that weren't building anymore with this change?

cozzyd 3y ago
As I understand it, the main problem is autoconf-generated stuff with old versions of autoconf.
- pests 3y ago
  Yep, errors result in autoconf checks failing leading to features being disabled, symbols being removed and more all while the build still succeeds successfully.
  - rwmj 3y ago
    This was the danger, but I think Florian did something where he compared autoconf output before and after the change and identified problems that way.
fweimer 3y ago
Packages fail to build after a while all the time. The maintainer fixes them (preferably using an upstream patch), and we move on. The issue with this set of compiler changes was that a lot of software builds successfully, but the new build suddenly has expected features missing. This happened with the previous attempt: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AL3PXQ3HX26PCF5PYDZ5RU7VJZSBZEPQ/#7I7DBPE6T52TH4XA5SN2DI2HFPAVBYHT https://lists.fedoraproject.org/archives/list/devel@lists.fe... That happened in 2016. In 2019, we undertook another attempt, this time with config.log/config.h diffing, but for various reasons stopped after fixing a few dozen packages, so it never went to the Fedora/upstream proposal stage. After Xcode and Clang the changed the defaults, it was somewhat easier to convince people that we should get Fedora & upstreams ready for a future GCC change. It also helped that Gentoo has been pushing fixes for Clang compatibility upstream for a while (https://bugs.gentoo.org/408963 https://bugs.gentoo.org/408963, with a broader scope in https://bugs.gentoo.org/870412 https://bugs.gentoo.org/870412).