On Wed, 22 Jun 2022 at 10:25, Jonathan Wakely wrote: > > 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.
P.S. there's a typo in the Subject: "symlnks" not "symlinks". I don't know if you intend to use that as the Git commit summary line. > > 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.
