On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++ <libstd...@gcc.gnu.org> wrote: > > > Several filesystem tests expect to be able to create symlinks even > when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing > the amount of testing of other filesystem features. > > They are already skipped for mingw targets. I've extended the > skipping to other targets in which _GLIBCXX_HAVE_SYMLINK is > undefined. > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > aarch64-rtems6. Ok to install?
OK. I'd like to clean this up so the tests don't rely on the "internal" HAVE_SYMLINK macro. We could add something like this to testsuite/util/testsuite_fs.h #if defined(__MINGW32__) || defined(__MINGW64__) \ || !defined (_GLIBCXX_HAVE_SYMLINK) # define NO_SYMLINKS #endif and then use that in the tests. That way the private macro is only checked in one place. We can do that later though. > > PS: Testing with trunk was somewhat impaired by various changes in the > filesystem implementation and tests that cause new failures on rtems6 The only significant changes are for PR104161 but the directory iterators did change fairly significantly. Which tests are failing? I might be able to point you to the cause much faster than you can debug it yourself.
