Bug 1929043

Summary: std::filesystem::_Dir_base::advance(bool, std::error_code&) not defined
Product: Red Hat Enterprise Linux 8 Reporter: Kefu Chai <kchai>
Component: gcc-toolset-9Assignee: Marek Polacek <mpolacek>
Status: CLOSED WONTFIX QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.2CC: ahajkova, jakub
Target Milestone: rcKeywords: Bugfix
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-17 02:28:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kefu Chai 2021-02-16 04:45:16 UTC
Description of problem:

std::filesystem::_Dir_base::advance(bool, std::error_code&) not defined

Version-Release number of selected component (if applicable):


How reproducible:

constantly reproducible.

Steps to Reproduce:

$ cat FindStdFilesystem_test.cc
#if __has_include(<filesystem>)
#include <filesystem>
namespace fs = std::filesystem;
#elif __has_include(<experimental/filesystem>)
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
#else
#error std::filesystem not available!
#endif

int main() {
    fs::create_directory("sandbox");
    fs::remove_all("sandbox");
}

$ scl enable gcc-toolset-9 bash

$ g++ -std=c++17 FindStdFilesystem_test.cc
/bin/ld: a.out: hidden symbol `_ZNSt10filesystem9_Dir_base7advanceEbRSt10error_code' isn't defined
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Actual results:

the code using std::filesystem fails to link.

Expected results:

the code using std::filesystem links.

Additional info:

$ c++filt _ZNSt10filesystem9_Dir_base7advanceEbRSt10error_code
std::filesystem::_Dir_base::advance(bool, std::error_code&)

$ nm -C /opt/rh/gcc-toolset-9/root/usr/lib/gcc/aarch64-redhat-linux/9/libstdc++_nonshared.a | grep _Dir_base
                 U std::filesystem::_Dir_base::advance(bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 n std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
                 U std::filesystem::_Dir_base::advance(bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 n std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)

$ dnf list installed gcc-toolset-9-gcc-c++
Installed Packages gcc-toolset-9-gcc-c++.aarch64 9.2.1-2.3.el8 @AppStream

please note, our building host is running CentOS8, and is using GTS from AppStream. but i think this issue also applies to RHEL8.

this issue is only observed on aarch64. on amd64, i have:

$ nm -C /opt/rh/gcc-toolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++_nonshared.a | grep _Dir_base
0000000000000000 W std::filesystem::_Dir_base::advance(bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 n std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::advance(bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 W std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)
0000000000000000 n std::filesystem::_Dir_base::_Dir_base(char const*, bool, std::error_code&)

$ dnf list installed gcc-toolset-9-gcc-c++
Installed Packages gcc-toolset-9-gcc-c++.x86_64 9.2.1-2.3.el8 @rhel-8-for-x86_64-appstream-rpms

Comment 1 Kefu Chai 2021-02-16 04:54:21 UTC
i filed a similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1853900 before.  but a different symbol was missing in that one, and we only have this link failure on aarch64.

Comment 2 Marek Polacek 2021-02-16 15:38:05 UTC
There indeed is a problem with that symbol in GTS 9:

308: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN   UND _ZNSt10filesystem9_Dir_base7advanceEbRSt10error_code

all of these issues were fixed in GTS 10.  I suppose you can't switch to gcc-toolset-10-gcc?

Comment 3 Marek Polacek 2021-02-16 18:49:28 UTC
Also, -std=c++17 is still experimental in GCC 9, so I'm not sure if we will be able to provide updates for it.

Comment 4 Kefu Chai 2021-02-17 02:28:25 UTC
hi Marek,

thank you for your prompt reply!

regarding C++17 support on GCC-9, I was mostly referencing 

- https://gcc.gnu.org/projects/cxx-status.html#cxx17
- https://gcc.gnu.org/gcc-9/changes.html#libstdcxx

but yeah, since we have GCC-10, there is no good reason to stick with GCC-9! I will try to contact our lab administrator to see if we can switch to RHEL8 for using GTS-10. as, FWIW, CentOS8's GTS-10 is currently broken. see https://bugs.centos.org/view.php?id=17860.

I am closing this ticket as "won't fix".

Comment 5 Marek Polacek 2021-02-17 02:34:05 UTC
(In reply to Kefu Chai from comment #4)
> hi Marek,
> 
> thank you for your prompt reply!
> 
> regarding C++17 support on GCC-9, I was mostly referencing 
> 
> - https://gcc.gnu.org/projects/cxx-status.html#cxx17
> - https://gcc.gnu.org/gcc-9/changes.html#libstdcxx
> 
> but yeah, since we have GCC-10, there is no good reason to stick with GCC-9!
> I will try to contact our lab administrator to see if we can switch to RHEL8
> for using GTS-10. as, FWIW, CentOS8's GTS-10 is currently broken. see
> https://bugs.centos.org/view.php?id=17860.
> 
> I am closing this ticket as "won't fix".

Thanks for understanding!  Note that we don't really consider C++17 to be stable in GCC 9,
but it is considered stable in GCC 10.  So switching to GCC 10 definitely makes sense from
this point of view.