Description of problem: I've been using modules for some weeks with no problem, but I've run into a strangely specific case where std::format ended up needing symbols that don't get linked in. The problem is reproducible with these simple files: /** library.cppm **/ module; export module my_library; import std; export std::string format_error_code(int ev) { return std::format("Unknown module error code {}", ev); } /** main.cpp **/ import my_library; import std; int main() { std::string error_message = format_error_code(99); std::cout << error_message << std::endl; return 0; } /** Compilation **/ $ g++ -std=c++26 -fmodules -fsearch-include-path -c bits/std.cc -o std.o $ g++ -std=c++26 -fmodules -c library.cppm -o library.o $ g++ -std=c++26 -fmodules -c main.cpp -o main.o $ g++ main.o library.o std.o -o minimal_bug_report -std=c++26 /usr/bin/ld: library.o: in function `std::span<char, 18446744073709551615ul>::span<12ul>(char (&) [12ul])': library.cppm:(.text._ZNSt4spanIcLm18446744073709551615EEC2ILm12EEERAT__c[_ZNSt4spanIcLm18446744073709551615EEC5ILm12EEERAT__c]+0x25): undefined reference to `std::span<char, 18446744073709551615ul>::__v<12ul>' /usr/bin/ld: library.o: in function `std::span<char, 18446744073709551615ul>::span<256ul>(char (&) [256ul])': library.cppm:(.text._ZNSt4spanIcLm18446744073709551615EEC2ILm256EEERAT__c[_ZNSt4spanIcLm18446744073709551615EEC5ILm256EEERAT__c]+0x25): undefined reference to `std::span<char, 18446744073709551615ul>::__v<256ul>' collect2: error: ld returned 1 exit status Version-Release number of selected component (if applicable): gcc (GCC) 15.2.1 20251111 (Red Hat 15.2.1-4) Fedora 43. How reproducible: Always with this specific std::format call with an int. Strangely I've used format for many other types and have no problem. Actual results: Linker failure Expected results: Creation of executable Additional info: Using -std=c++23 also produces the problem If I don't use modules and just #include <format>, no linker error.
This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122625 which was fixed upstream last week and so should get fixed in Fedora the next time the gcc package is updated.
(In reply to Andrew Potter from comment #0) > How reproducible: > Always with this specific std::format call with an int. Strangely I've used > format for many other types and have no problem. That basically means a basic modern Hello world C++ application won't compile in gcc-0:15.2.1-4.fc43.x86_64! I created a simple command-line reproducer (just needs a working directory to create `gcm.cache/std.gcm`) that can help Fedora developers and QA check for the bug smoothly. I used to be a package maintainer, too. :) Reproducer: g++ -std=c++26 -fmodules -fsearch-include-path bits/std.cc -c echo -ne 'import std;\nint main() { std::println("Hello world."); }\n' | g++ -std=c++26 -fmodules -xc++ - gcc-0:15.2.1-4.fc43.x86_64 - Actual results same as in the original bug report. gcc-0:15.2.1-2.fc43.x86_64 - Works smoothly. Temporary fix: dnf -y downgrade gcc-15.2.1-2.fc43 gcc-c++-15.2.1-2.fc43 libstdc++-15.2.1-2.fc43 libstdc++-devel-15.2.1-2.fc43
(In reply to Jonathan Wakely from comment #1) > This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122625 which was fixed > upstream last week and so should get fixed in Fedora the next time the gcc > package is updated. But then why gcc-15.2.1-2.fc43 builds and gcc-0:15.2.1-4.fc43 fails? Is there any explanation for that?
The explanation is in the upstream bug that I linked to. The bug that caused this was backported to the gcc-15 branch on October 26 as https://gcc.gnu.org/r15-10474-g59213fd40fe5f272f603f5b8303d2c371f05c7a5 so snapshots from the gcc-15 branch before that date don't have the bug, e.g. gcc-15.2.1-2.fc43. Snapshots from after that date have the bug.
gcc-15.2.1-2.fc43 was built on November 12. That is after October 26 and before November 15 when the bug was fixed upstream.
(In reply to Jonathan Wakely from comment #4) > The bug that caused this was backported to the gcc-15 branch on October 26 > as https://gcc.gnu.org/r15-10474-g59213fd40fe5f272f603f5b8303d2c371f05c7a5 > so snapshots from the gcc-15 branch before that date don't have the bug, > e.g. gcc-15.2.1-2.fc43. Snapshots from after that date have the bug. Thanks. So the bug was part of a backported change but for the bug fix we wait for the next upstream release, is that right? Is there a possibility to include the above test in any sort of Fedora package test suite? I've been out of Red Hat for a while so I might not have the best idea of how things work now.
Fedora gcc isn't updated only with new upstream releases, on the other side I don't want to update it every week. Right now upstream there is bug fixing season, where lots of bugs are fixed on the trunk and eventually many of those also backported to release branches, so doing the next update in mid December is best I'd say.
(In reply to Pavel Šimerda from comment #6) > Thanks. So the bug was part of a backported change but for the bug fix we > wait for the next upstream release, is that right? No. As I said in comment 1, it will be updated the next time gcc is updated in Fedora. The last update brought the backported bug, the next update will bring the backported fix.
(In reply to Jonathan Wakely from comment #8) > No. As I said in comment 1, it will be updated the next time gcc is updated > in Fedora. The last update brought the backported bug, the next update will > bring the backported fix. Thank you for clarification.
FEDORA-2025-81084b2f7c (gcc-15.2.1-5.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-81084b2f7c
FEDORA-2025-90bad6fccc (gcc-15.2.1-5.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-90bad6fccc
FEDORA-2025-81084b2f7c has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-81084b2f7c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-81084b2f7c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-90bad6fccc has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-90bad6fccc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-90bad6fccc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-81084b2f7c (gcc-15.2.1-5.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-90bad6fccc (gcc-15.2.1-5.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.