[PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

[Jonathan Wakely]

On Wed, 22 Jun 2022 at 10:25, Jonathan Wakely wrote:
>
> On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++
> <libstdc++@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.