Thanks for the quick response, Stephen.

Yes, you're right,
/usr/lib/gcc/i686-w64-mingw32/6.1-win32/include/c++/experimental is present
and populated from debian's g++-mingw-w64-i686 package, with the exception
of filesystem.  So this issue applies to enabling experimental::filesystem
only.

The following files are missing from mingw's include dir compared to
debian's g++-6:

    bits/fs_dir.h bits/fs_fwd.h bits/fs_ops.h bits/fs_path.h
bits/lfts_config.h filesystem


Regarding enabling experimental features, this appears to be a configure
flag accepted by the crt only:

    mingw-w64-v5.0.0/mingw-w64-crt/configure --help | fgrep -i experimental
-A1

  --enable-experimental   Enable experimental features, valid options are
                          comma separated combination of all, dfp,
printf128,
                          registeredprintf. Refer to experimental.txt for
                          descriptions.

Perhaps this is referring to some different experimental features; I came
across it in some older documentation that may not be relevant any more,
and the mentioned experimental.txt is missing.


With regards to an example to check if the windows implementation works,
the following small program compiles and executes fine on linux with g++
natively (of course), and also on windows using the latest mingw-builds
binary, but cannot be compiled under Debian's mingw-w64:

    // Compile with g++ experimental_test.cpp -lstdc++fs
    #include <iostream>
    #include <experimental/filesystem>

    auto main(int argc, char *argv[])->int {
      // use std::experimental::filesystem to check if a specified file
exists.
      if(argc != 2) {
        std::cerr << "Usage: " << argv[0] << " [filename]" << std::endl;
        return EXIT_FAILURE;
      }
      std::string const filename(argv[1]);
      std::error_code error;
      if(std::experimental::filesystem::exists(filename, error)) {
        std::cout << "File " << filename << " exists." << std::endl;
      } else {
        std::cout << "File " << filename << " does not exist." << std::endl;
      }
      return EXIT_SUCCESS;
    }

As expected, /usr/bin/i686-w64-mingw32-g++-posix and
/usr/bin/i686-w64-mingw32-g++-win32 both fail with:

    experimental_test.cpp:4:39: fatal error: experimental/filesystem: No
such file or directory

Copying over the missing headers from /usr/include/c++/6/experimental to
/usr/lib/gcc/i686-w64-mingw32/6.1-posix/include/c++/experimental is all
that's required to allow the program to compile.  However, linking fails
due to the absence of the stdc++fs library:

    /usr/bin/i686-w64-mingw32-ld: cannot find -lstdc++fs

>From this it looks like all that's required for the posix version of
mingw-w64 to enable std::experimental::filesystem is to include the headers
and compile that library.  However, the process may be somewhat more
involved with the win32 version than the posix version, but if that's the
case, would suggest that enabling it for just the posix build would already
be sufficient.


Regards,
Riot


On 9 December 2016 at 19:57, Stephen Kitt <sk...@debian.org> wrote:

> Control: severity -1 wishlist
>
> Hi,
>
> Thanks for taking the time to file this!
>
> On Wed, 07 Dec 2016 17:58:20 +0000, Riot <rain.back...@gmail.com> wrote:
> > Experimental support is not currently enabled in Debian's build of the
> > mingw-w64 cross-compiler.
>
> I'm pretty sure it is: look
> at /usr/lib/gcc/{i686,x86_64}-w64-mingw32/6.2-{posix,win32}/
> include/c++/experimental
> for the supported features.
>
> > It's being used increasingly frequently for things like
> > std::experimental::filesystem in a lot of projects, and is enabled by
> > default in Debian's native g++.   Mingw-w64's own upstream binary builds
> > for Windows (such as "mingw-builds") all have experimental support
> enabled
> > also.
> >
> > For consistency it would be very helpful to enable this in Debian's
> binary
> > build, as this currently prevents cross-compiling a number of the same
> > projects that compile fine with upstream's binary releases and with
> > Debian's g++ binaries.
> >
> > The relevant flag to add is just configure --enable-experimental.
>
> I haven't found any sign of an --enable-experimental option (the available
> options are defined in libstdc++-v3/acinclude.m4 in the gcc source). For
> most
> experimental (TS) features, no flag is required, they're enabled by default
> if the target platform supports them; this is the case for MinGW-w64
> Windows
> targets. The only exception is the filesystem TS, which is only enabled by
> default on POSIX systems where it's known to work (see
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html for
> details)
> and requires --enable-libstdcxx-filesystem-ts; is that what you're after?
> It's worth noting the caveats in
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/
> using_dynamic_or_shared.html#manual.intro.using.linkage.experimental
> too.
>
> Do you have an example project I could use to check that the Windows
> implementation works? Although it currently fails to build, so enabling it
> would probably take a bit of effort:
>
> ../../../../../../src/libstdc++-v3/src/filesystem/dir.cc: In function
> 'std::experimental::filesystem::v1::__cxx11::_Dir
> {anonymous}::open_dir(const std::experimental::filesystem::v1::__cxx11::path&,
> std::experimental::filesystem::v1::directory_options, std::error_code*)':
> ../../../../../../src/libstdc++-v3/src/filesystem/dir.cc:91:40: error:
> cannot convert '_WDIR*' to 'DIR*' in initialization
>      if (DIR* dirp = ::opendir(p.c_str()))
>                                         ^
> ../../../../../../src/libstdc++-v3/src/filesystem/dir.cc: In constructor
> 'std::experimental::filesystem::v1::__cxx11::
> recursive_directory_iterator::recursive_directory_iterator(const
> std::experimental::filesystem::v1::__cxx11::path&,
> std::experimental::filesystem::v1::directory_options, std::error_code*)':
> ../../../../../../src/libstdc++-v3/src/filesystem/dir.cc:249:38: error:
> cannot convert '_WDIR*' to 'DIR*' in initialization
>    if (DIR* dirp = ::opendir(p.c_str()))
>                                       ^
>
> (I should probably check niXman's builds to see if there are any other
> relevant options.)
>
> Regards,
>
> Stephen
>

Reply via email to