On Wed, Jan 7, 2026 at 4:28 PM Daniel P. Berrangé <[email protected]> wrote:
> On Wed, Jan 07, 2026 at 04:16:42PM +0000, Ian McInerney wrote: > > Hi all, > > > > I was looking into the Koschei-reported failure of the arpack package on > > F44 (https://koschei.fedoraproject.org/package/arpack?collection=f44), > and > > it seems to have started failing immediately after the GCC update landed > in > > rawhide. > > > > The thing I can't understand is the failure is actually in a configure > > check for a header. It uses the eigen3 library (so installs > eigen3-devel), > > and the configure check for that library has passed, but the subsequent > > check for the actual "Eigen/Sparse" header fails. The tests it does are > > standard autoconf macros ( > > > https://github.com/opencollab/arpack-ng/blob/f73592dd1e5e39c469ade3587db76794ddfa171d/configure.ac#L92 > ), > > so I am perplexed why it seems this GCC update being merged has caused > them > > to start failing when the eigen3 package hasn't changed at all. > > > > I am not that experienced with autoconf, so does anyone have any thoughts > > on what might be causing this? > > You'll need to get the 'config.log' file from a failed configure run, > and compare it to a previous successful configure run with GCC 15. > In these situations typically you'll find some historical bad assumption > in the way the autoconf check was written that has finally been invalidated > by the new GCC or glibc. > > Hi Daniel, Thanks for the pointer. I dove into the config.log and output from a working/non-working version, and it looks like it might be the GCC bump to the GNU++20 dialect by default that is breaking it. The main difference I see is that the working build has > checking for g++ option to enable C++11 features... none needed but the broken build now has > checking for g++ option to enable C++11 features... -std=gnu++11 which then will force a gnu++11 standard dialect for the compilation (the working would use the default GCC 15 dialect of gnu++17). That gnu++11 dialect breaks eigen3 because it wants C++14. Looking at the configure file, that check is actually specified as part of the AC_PROG_CXX command I believe, and it is failing because the autoconf check has the following error for gnu++20 generated by the conftest.cpp program it generates: 347 conftest.cpp:194:22: error: invalid conversion from 'const char8_t*' to 'const char*' [-fpermissive] 348 194 | char const *utf8 = u8"UTF-8 string \u2500"; 349 | ^~~~~~~~~~~~~~~~~~~~~~~ 350 | | 351 | const char8_t* which is the unicode literals test: 554 | { 555 | // Unicode literals 556 | char const *utf8 = u8"UTF-8 string \u2500"; 557 | char16_t const *utf16 = u"UTF-8 string \u2500"; 558 | char32_t const *utf32 = U"UTF-32 string \u2500"; 559 | } I'm not sure the best way of fixing this though - is it a bug in the autoconf tool for how it generates this test file now with GCC 16, or is there a way to override this check and force say C++14 in the downstream code and not have it try this test. Thanks, -Ian > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > -- > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
