[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Andrew Pinski changed: What|Removed |Added CC||tower120 at gmail dot com --- Comment #29 from Andrew Pinski --- *** Bug 86507 has been marked as a duplicate of this bug. ***
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #28 from Jonathan Wakely --- We might want to mark some tests as XFAIL for *-*-mingw* targets.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #27 from Liu Hao --- Some tests failed, but despite the failure, all tests compiled now.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #26 from Liu Hao --- Created attachment 44235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44235=edit test results for trunk
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #25 from Liu Hao --- Created attachment 44234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44234=edit test results for trunk
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #24 from Liu Hao --- (In reply to Jonathan Wakely from comment #23) > Nothing has been committed for gcc-8-branch so of course it isn't created. > > For trunk, did you read comment 14? Sorry didn't notice it. I started a new build just now.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #23 from Jonathan Wakely --- Nothing has been committed for gcc-8-branch so of course it isn't created. For trunk, did you read comment 14?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #22 from Liu Hao --- ``` lh_mouse@lhmouse-pc /e/GitHub/MINGW-packages/mingw-w64-gcc-git $ gcc --version gcc.exe (master HEAD with MCF thread model, built by LH_Mouse.) 9.0.0 20180604 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is the list of DLLs installed with `make install`: ``` libatomic-1.dll libgcc_s_seh-1.dll libgomp-1.dll libquadmath-0.dll libssp-0.dll libstdc++-6.dll ```
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #21 from Liu Hao --- On current branch master [1] and gcc-8-branch the libstdc++fs DLL is not created for x86_64-w64-mingw32. Please re-open. [1] remotes/origin/master 84b3cf31c30 PR target/85832 PR target/86036 * config/i386/sse.md (_eq3
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #20 from Jonathan Wakely --- Probably not.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #19 from Jordi Vilar --- (In reply to Jonathan Wakely from comment #18) > That was already done two weeks ago by r260479 Thank you! And a last question: Do you plan to merge both patches into the gcc 8 branch?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #18 from Jonathan Wakely --- That was already done two weeks ago by r260479
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Jordi Vilar changed: What|Removed |Added CC||development at jordi dot vilar.cat --- Comment #17 from Jordi Vilar --- I think the patch is not including the required changes in in order to properly handle path arguments. Specifically, both constructors and methods open() need an additional overload taking const wchar_t*, as required per specs: 30.9.1 Header synopsis [...] 3 In this subclause, member functions taking arguments of const filesystem::path::value_type* are only be provided on systems where filesystem::path::value_type (30.10.7) is not char. [ Note: These functions enable class path support for systems with a wide native path character type, such as wchar_t. —end note ] This involves methods: basic_filebuf::open(const filesystem::path::value_type* s, ios_base::openmode mode); explicit basic_ifstream::basic_ifstream(const filesystem::path::value_type* s, ios_base::openmode mode = ios_base::in); void basic_ifstream::open(const filesystem::path::value_type* s, ios_base::openmode mode = ios_base::in); explicit basic_ofstream::basic_ofstream(const filesystem::path::value_type* s, ios_base::openmode mode = ios_base::out); void basic_ofstream::open(const filesystem::path::value_type* s, ios_base::openmode mode = ios_base::out); explicit basic_fstream::basic_fstream(const std::filesystem::path::value_type* s, ios_base::openmode mode = ios_base::in|ios_base::out); void basic_fstream::open(const std::filesystem::path::value_type* s, ios_base::openmode mode = ios_base::in|ios_base::out); I hope this helps
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #16 from Christophe Lyon --- Hi Jonathan, After this patch, the aarch64_be-none-elf and aarch64-none-elf configurations fail to configure libstdc++ because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203 configure:80055: checking for link configure:80055: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #15 from Jonathan Wakely --- P.S. thanks to niXman for the patch that inspired the approach used.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- The Filesystem library now builds and mostly works on MinGW (for both the TS and C++17 versions). The library is not enabled by default for mingw targets, so you need to build GCC with --enable-libstdcxx-filesystem-ts If people can test and confirm it works fine for both mingw and mingw-w64 then we can enable it by default.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Thu May 31 19:20:24 2018 New Revision: 261034 URL: https://gcc.gnu.org/viewcvs?rev=261034=gcc=rev Log: PR libstdc++/78870 support std::filesystem on Windows PR libstdc++/78870 support std::filesystem on Windows * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Check for link, readlink and symlink. * include/bits/fs_path.h (path::operator/=(const path&)): Move definition out of class body. (path::is_absolute(), path::_M_append(path)): Likewise. (operator<<(basic_ostream, const path&)): Use std::quoted directly. (operator>>(basic_istream, path&)): Likewise. (u8path): Reorder definitions and fix Windows implementation. (path::is_absolute()): Define inline and fix for Windows. [!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::operator/=(const path&)): Define POSIX version inline. (path::_M_append(path)): Define inline. * include/experimental/bits/fs_path.h (path::is_absolute()): Move definition out of class body. (operator<<(basic_ostream, const path&)): Fix type of delimiter and escape characters. (operator>>(basic_istream, path&)): Likewise. (path::is_absolute()): Define inline and fix for Windows. * src/filesystem/dir-common.h (__gnu_posix): New namespace. (__gnu_posix::char_type, __gnu_posix::DIR, __gnu_posix::dirent) (__gnu_posix::opendir, __gnu_posix::readdir, __gnu_posix::closedir): Define as adaptors for Windows functions/types or as using-declarations for POSIX functions/types. (_Dir_base, get_file_type): Qualify names to use declarations from __gnu_posix namespace. (_Dir_base::is_dor_or_dotdot): New helper functions. * src/filesystem/dir.cc (_Dir, recursive_directory_iterator): Qualify names to use declarations from __gnu_posix namespace. * src/filesystem/ops-common.h (__gnu_posix): New nested namespace. (__gnu_posix::open, __gnu_posix::close, __gnu_posix::stat_type) (__gnu_posix::stat, __gnu_posix::lstat, __gnu_posix::mode_t) (__gnu_posix::chmod, __gnu_posix::mkdir, __gnu_posix::getcwd) (__gnu_posix::chdir, __gnu_posix::utimbuf, __gnu_posix::utime) (__gnu_posix::rename, __gnu_posix::truncate, __gnu_posix::char_type): Define as adaptors for Windows functions/types or as using-declarations for POSIX functions/types. (stat_type, do_copy_file): Qualify names to use declarations from __gnu_posix namespace. (do_space): Declare new function. (make_file_type): Only use S_ISLNK if defined. * src/filesystem/ops.cc (char_ptr, filesystem::canonical): Use path::value_type not char. (filesystem::copy, create_dir, filesystem::create_directory): Qualify names to use declarations from __gnu_posix namespace. (filesystem::create_hard_link): Check HAVE_LINK autoconf macro and add implementation for Windows. (filesystem::create_symlink): Check HAVE_SYMLINK autoconf macro. (filesystem::current_path(error_code&)): Use __gnu_posix::getcwd. [!_PC_PATH_MAX]: Don't use pathconf. [PATH_MAX]: Use if defined. (filesystem::current_path(const path&, error_code&)) (filesystem::equivalent, do_stat, filesystem::hard_link_count) (filesystem::last_write_time, filesystem::permissions): Use names from __gnu_posix. (filesystem::read_symlink): Check HAVE_READLINK autoconf macro. (filesystem::remove) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Add implementation for Windows. (filesystem::rename, filesystem::resize_file): Use names from __gnu_posix. (filesystem::space): Use do_space. [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Get absolute path to directory. (filesystem::status, filesystem::symlink_status): Use names from __gnu_posix. (filesystem::temp_directory_path): Add implementation for Windows. * src/filesystem/path.cc (dot): Define constant. (path::replace_extension): Use dot. (path::_M_find_extension): Likewise. Use path::string_type not std::string. (path::_M_split_cmpts): Use dot. (filesystem_error::_M_get_what): Use u8string() not native(). * src/filesystem/std-dir.cc (_Dir, recursive_directory_iterator): Qualify names to use declarations from __gnu_posix namespace. * src/filesystem/std-ops.cc (filesystem::absolute(const path&)): Use correct error_code. (filesystem::absolute(const path&, error_code&)): Add implementation for Windows. (char_ptr, filesystem::canonical): Use path::value_type not char. (do_copy_file): Use names from __gnu_posix. [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Do not use
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Jonathan Wakely changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #12 from Jonathan Wakely --- *** Bug 85670 has been marked as a duplicate of this bug. ***
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to niXman from comment #10) > (In reply to Jonathan Wakely from comment #9) > > There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html > > > > I haven't reviewed or tested it yet. > > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00772.html > > Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu. Adding "patch" keyword
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #10 from niXman --- (In reply to Jonathan Wakely from comment #9) > There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html > > I haven't reviewed or tested it yet. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00772.html Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-16 Ever confirmed|0 |1 --- Comment #9 from Jonathan Wakely --- There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html I haven't reviewed or tested it yet.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #8 from Jan Niklas Hasse --- I'm not interested in doing all this work again from scratch, especially since working with the Windows API is a pain.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #7 from Jonathan Wakely --- (In reply to Jan Niklas Hasse from comment #6) > According to https://www.gnu.org/licenses/license-list.html the Boost > License is GPL compatible. So when I mark the code I copied with the source, > it should work, shouldn't it? See the legal prerequisites. As it says, the FSF prefers to hold the copyright on all code contributed to GCC. If you copy somebody else's code you can't assign copyright to the FSF because you don't own the copyright. We could request all the authors of Boost.Filesystem to assign copyright, but I don't want to do that, I want an independent implementation (the Boost implementation doesn't follow exactly the same specification anyway). I'm not interested in simply copying the Boost.Filesystem code into GCC. If you want to use the Boost implementation then just use that, with appropriate preprocessor hackery and namespace aliases.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #6 from Jan Niklas Hasse --- > Yes. Okay thanks, I'll look into it. > You can't copy any code, that would be a copyright violation. It's OK to see > which Windows API functions Boost uses for a particular filesystem > operation, but if you're not sure what is covered by copyright law then it's > safer not to use another project at all. According to https://www.gnu.org/licenses/license-list.html the Boost License is GPL compatible. So when I mark the code I copied with the source, it should work, shouldn't it? > I was hoping that somebody who actually knows the Windows API would > contribute the code, so they already know what the appropriate functions are. I know the Windows API, but the details are hard to get right. Especially getting everything to be bug-free. Many man hours have already been spend on boost::filesystem and the API is similar to std::filesystem. Why should I re-invent the wheel?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #5 from Jonathan Wakely --- (In reply to Jan Niklas Hasse from comment #4) > Do you mean the part about legal paperwork in > https://gcc.gnu.org/contribute.html ? Yes. > And can I look at how boost::filesystem does this? You can't copy any code, that would be a copyright violation. It's OK to see which Windows API functions Boost uses for a particular filesystem operation, but if you're not sure what is covered by copyright law then it's safer not to use another project at all. I was hoping that somebody who actually knows the Windows API would contribute the code, so they already know what the appropriate functions are.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #4 from Jan Niklas Hasse --- > Great! Please read > https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html > especially the part about legal paperwork. Do you mean the part about legal paperwork in https://gcc.gnu.org/contribute.html ? > No. Just look at the existing code and figure out what the equivalent code > would be for Windows, and write an alternative implementation e.g. replace > calls to POSIX stat() with whatever Windows uses to query file properties, > and replace calls to POSIX chmod with whatever Windows uses to change file > permissions. And can I look at how boost::filesystem does this?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #3 from Jonathan Wakely --- (In reply to Jan Niklas Hasse from comment #2) > I'm willing to help. Great! Please read https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html especially the part about legal paperwork. > Is there an existing starting point for Windows? Can > boost::filesystem's implementation be used? No. Just look at the existing code and figure out what the equivalent code would be for Windows, and write an alternative implementation e.g. replace calls to POSIX stat() with whatever Windows uses to query file properties, and replace calls to POSIX chmod with whatever Windows uses to change file permissions.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #2 from Jan Niklas Hasse --- I'm willing to help. Is there an existing starting point for Windows? Can boost::filesystem's implementation be used?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #1 from Jonathan Wakely --- Because nobody who uses Windows has contributed any help to make it work. Nothing will change until somebody does that. I've written 100% of the filesystem code so far, but I'm not going to do the Windows implementation too.
