I'm experimentally rebuilding rawhide with the not-yet-released GCC 15 to see if anything breaks, and to help write the porting guide. See https://fedoraproject.org/wiki/User:Dmalcolm/gcc-15 My test build with GCC 15 failed: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed/build/8476076/ whereas my test build with GCC 14 succeeded: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477638/ Looking at the failure logs https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476076-amdsmi/builder-live.log.gz I see: | ^~~~~~~~~~~~~~~~~ /builddir/build/BUILD/amdsmi-6.3.0-build/amdsmi-rocm-6.3.0/rocm_smi/include/rocm_smi/rocm_smi_common.h:149:5: error: ‘uintptr_t’ does not name a type 149 | uintptr_t func_id_iter; | ^~~~~~~~~ /builddir/build/BUILD/amdsmi-6.3.0-build/amdsmi-rocm-6.3.0/rocm_smi/include/rocm_smi/rocm_smi_common.h:53:1: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’ 52 | #include <unordered_set> +++ |+#include <cstdint> 53 | Looks like this header should have been included, but old versions of the C++ stdlib happened to do it for you, so hopefully the fix is to simply add that #include. Reproducible: Always
https://github.com/ROCm/amdsmi/pull/70 submitted upstream
https://src.fedoraproject.org/rpms/amdsmi/c/6ddd3e714bd10c2eb7fc0c5985bc8cdbcf841275?branch=rawhide
That fix is incorrect, strictly speaking. <stdint.h> is guaranteed to declare the names in the global namespace, and *might* also declare them in namespace std. <cstdint> is guaranteed to declare the names in namespace std, and *might* also declare them in the global namespace. Since the code uses those names unqualified (i.e. uintptr_t not std::uintptr_t) the portable and correct fix is to include <stdint.h> (or alternatively, include <cstdint> then add `using std::uintptr_t;` for each name, or `using namespace std;`). In practice, with GCC's C++ stdlib the fix works, because <cstdint> does declare the names in both std and the global namespace.
Then the gcc warning suggesting the fix needs to change otherwise everyone facing this issue will follow this advice.
Yes I know: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110930
I am seeing this problem in other packages, atm clang build. This update may roil the F42 release. Can this problem be hidden by a compiler change ? Can update to gcc-compat be rolled out quickly ?
The packages need to be fixed, they're not valid C++. Reverting the GCC change will just mean the packages are never fixed, and we'll have the same problems in a year with GCC 16.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days