#737 can't include <filesystem> with mingw-w64 8.1

[crillion]

Hi.

I've just installed the newly released mingw-w64 8.1 (version x86_64-8.1.0-posix-seh-rt_v6-rev0).

The following program :

#include <filesystem>
int main()
{
}

compiled with this command :

g++ -pedantic -Wall -Wextra -std=c++17 program.cpp -o program_gpp.exe

causes many error messages, starting with :

C:/programs/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/bits/fs_path.h:237:47: error: no match for 'operator!=' (operand types are 'std::filesystem::__cxx11::path' and 'std::filesystem::__cxx11::path')
|| (__p.has_root_name() && __p.root_name() != root_name()))
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~

Can this be fixed ? Or is there something to be linked or similar ?

Many thanks,

 Marco

[Chris]

I'm also having this issue.

A solution for now would be to use msys2, install the MinGW version available (v7). And then prepend 'Experimental' into the filesystem header and namespace. Use the std flag, as you have. Link with '-lstdc++fs'. It does have a bug when removing files, no matter what one does - It will fail to delete due to permissions. But everything else seems to work.

[Jordi Vilar]

operator != is declared and defined in line 550, but referenced in line 237.

The problem is triggered by operator/= in line 233:

    path& operator/=(const path& __p)
    {
#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
      if (__p.is_absolute()
      || (__p.has_root_name() && __p.root_name() != root_name()))
    operator=(__p);
      else
    {
      string_type __pathname;
      if (__p.has_root_directory())
        __pathname = root_name().native();
      else if (has_filename() || (!has_root_directory() && is_absolute()))
        __pathname = _M_pathname + preferred_separator;
      __pathname += __p.relative_path().native(); // XXX is this right?
      _M_pathname.swap(__pathname);
      _M_split_cmpts();
    }
#else
      // Much simpler, as any path with root-name or root-dir is absolute.
      if (__p.is_absolute())
    operator=(__p);
      else
    {
      if (has_filename() || (_M_type == _Type::_Root_name))
        _M_pathname += preferred_separator;
      _M_pathname += __p.native();
      _M_split_cmpts();
    }
#endif
      return *this;
    }

As you can see, if the macro _GLIBCXX_FILESYSTEM_IS_WINDOWS is not defined, then everything is declared in the correct order. But if that macro is defined, then the operator != is referenced, but that operator has not beed declared yet.

BUT, the same problem happens once this first issue is fixed. This time in line 412:
~~~~~~~~~~~~.cpp
path& _M_append(string_type&& __str)
{

ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS

  operator/=(path(std::move(__str)));

else

  if (!_M_pathname.empty() && !_S_is_dir_sep(_M_pathname.back())
  && (__str.empty() || !_S_is_dir_sep(__str.front())))
_M_pathname += preferred_separator;
  _M_pathname += __str;
  _M_split_cmpts();

endif

  return *this;
}

~~~~~~~~~~~~~

if the macro _GLIBCXX_FILESYSTEM_IS_WINDOWS is not defined, then everything is declared in the correct order. But if that macro is defined, then the path constructor forces the instantiation of path::__is_encoded_char, but this templated is not expected to be instantiated yet, as it is specialized afterwards.

So, the conclusion is that this header has been tested ONLY with the _GLIBCXX_FILESYSTEM_IS_WINDOWS macro undefined, and in order to support it, some declarations and specializations MUST be moved up.

[Jordi Vilar]

This has been fixed in trunk:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870

Required patches are:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=260479
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261034

Could you please generate a new release by porting those patches? (I think they didn't merge the patches to the gcc 8 branch)

Thank you!

[jonathan]

Hi, I have this problem too.

I'm looking for a new version too !

regards

Jonathan

[DuffsDevice]

Still open?

[Andéol Evain]

We are having the same issue here. Looking forward to see these patches included in a MinGW update.

[Chris]

This is no longer a bug. Where are you installing mingw from?

Use msys2.

[Jordi Vilar]

This is fixed in version 9.x. Unfortunately, there is no mingw-w64 build for version 9.x here. As Chris suggested, msys2 includes it. But it would be very convenient to have it also here as usual.

[Andéol Evain]

I was using version 8.1.0, and was unaware version 9 aven existed. I installed Mingw as a standalone.
I'll try installing with msys2. Thanks a lot.

[Michael Gooch]

why tell us to use msys2? shouldn't other mingw releases be updated as well?

[Chris]

The question you should be asking yourself is why aren't you using msys2? It has the best Linux compatible base and includes a lot more libraries than other mingw distributors. Perhaps they see msys2 as a superior release.

[Vishal Subramanyam]

I am facing this issue even now with the standalone version of MinGW without MSYS2. Will the Windows binary release be updated anytime soon?