make[1]: Entering directory '/home/xx/CppMicroServices/build' [ 5%] Built target usResourceCompiler [ 7%] Building CXX object util/CMakeFiles/util.dir/src/FileSystem.cpp.o /home/xx/CppMicroServices/util/src/FileSystem.cpp: In function ‘std::string cppmicroservices::util::GetExecutablePath()’: /home/xx/CppMicroServices/util/src/FileSystem.cpp:122:3: error: ‘uint32_t’ was not declared in this scope 122 | uint32_t bufsize = MAXPATHLEN; | ^~~~~~~~ /home/xx/CppMicroServices/util/src/FileSystem.cpp:71:1: note: ‘uint32_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’? 70 | #include <sys/stat.h> +++ |+#include <cstdint> $ cat /etc/os-release NAME="Fedora Linux" VERSION="39 (Workstation Edition Prerelease)" ID=fedora VERSION_ID=39 VERSION_CODENAME="" PLATFORM_ID="platform:f39" PRETTY_NAME="Fedora Linux 39 (Workstation Edition Prerelease)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:39" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=rawhide SUPPORT_END=2024-05-14 VARIANT="Workstation Edition" VARIANT_ID=workstation $ echo | g++ -E -Wp,-v -xc++ /dev/null 2>&1 | grep -E -o '(/usr)?/include/c\+\+/\S+' /include/c++/13 /include/c++/13/x86_64-redhat-linux /include/c++/13/backward It seems the include path is not correct. It should be /usr//include/c++/13. Reproducible: Always Steps to Reproduce: 1. Build CppMicroServices. 2. You'll see the build errors. Actual Results: Build fails. Expected Results: Build pass.
Please just apply the fixit hint from error message. Sometimes missing #include directives are exposed when other headers remove indirect #include directives because they are no longer needed.
Obviously it can't be fixed by the hint. The same source codes can be built successfully in below environment. So please help to check. $ cat /etc/os-release NAME="Fedora Linux" VERSION="36 (Workstation Edition)" ID=fedora VERSION_ID=36 VERSION_CODENAME="" PLATFORM_ID="platform:f36" PRETTY_NAME="Fedora Linux 36 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:36" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=36 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=36 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" SUPPORT_END=2023-05-16 VARIANT="Workstation Edition" VARIANT_ID=workstation $ echo | g++ -E -Wp,-v -xc++ /dev/null 2>&1 | grep -E -o '(/usr)?/include/c\+\+/\S+' /include/c++/12 /include/c++/12/x86_64-redhat-linux /include/c++/12/backward
(In reply to xiangquan.liu from comment #2) > Obviously it can't be fixed by the hint. This isn't obvious to me. Have you tried it? What happens? It's not unusual that distribution updates expose buggy source code that only happens to compile by accident.
It seems the include path is not correct. It should be /usr//include/c++/13. is not true, it is just the weird way you're querying it. gcc is a relocatable package, so unless using a sysroot the include paths are dependent on where the compiler is installed and e.g the libstdc++ header paths usually look like /usr/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13 /usr/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/backward
And the fact that it "worked" in Fedora 36/GCC 12 doesn't tell anything. As https://gcc.gnu.org/gcc-13/porting_to.html says (but this is something that happens in almost every GCC release, so every year), libstdc++ headers have some includes required by the standard and some includes which are allowed but not required by the standard. Usually each year some of those implicit includes are dropped, so code relying on those implicit includes might stop compiling.