On 07/01/19 10:24 +0100, Christophe Lyon wrote:
Hi Jonathan
On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely <jwak...@redhat.com> wrote:
Move std::filesystem directory iterators and operations from
libstdc++fs.a to main libstdc++ library. These components have many
dependencies on OS support, which is not available on all targets. Some
additional autoconf checks and conditional compilation is needed to
ensure the files will build for all targets. Previously this code was
not compiled without --enable-libstdcxx-filesystem-ts but the C++17
components should be available for all hosted builds.
The tests for these components no longer need to link to libstdc++fs.a,
but are not expected to pass on all targets. To avoid numerous failures
on targets which are not expected to pass the tests (due to missing OS
functionality) leave the dg-require-filesystem-ts directives in place
for now. This will ensure the tests only run for builds where the
filesystem-ts library is built, which presumably means some level of OS
support is present.
Tested x86_64-linux (old/new string ABIs, 32/64 bit), x86_64-w64-mingw32.
Committed to trunk.
After this commit (r267616), I've noticed build failures for my
newlib-based toolchains:
aarch64-elf, arm-eabi:
In file included from
/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:57:
/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:142:11:
error: '::truncate' has not been declared
142 | using ::truncate;
| ^~~~~~~~
/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
In function 'void std::filesystem::resize_file(const
std::filesystem::__cxx11::path&, uintmax_t, std::error_code&)':
/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1274:19:
error: 'truncate' is not a member of 'posix'
1274 | else if (posix::truncate(p.c_str(), size))
| ^~~~~~~~
make[5]: *** [fs_ops.lo] Error 1
I'm not sure if there's an obvious fix? Note that I'm using a rather
old newlib version, if that matters.
That's probably the reason, as I didn't see this in my tests with
newlib builds.
The fix is to add yet another autoconf check and guard the uses of
truncate with a _GLIBCXX_USE_TRUNCATE macro. I'll do that now ...
