Problem when cross-compiling with libc++ in mingw

[jcelerier]

Hello, I am getting the following error from my compiler, in a relatively special build configuration:

/opt/mingw-llvm-toolchain/llvm-mingw/boost_1_67_0/boost/iostreams/positioning.hpp:52:10: error: no matching constructor for initialization of 'std::streampos' (aka 'fpos<int>')
{ return std::streampos(std::mbstate_t(), off); }
         ^              ~~~~~~~~~~~~~~~~~~~~~
/opt/mingw-llvm-toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/string:538:31: note: candidate constructor not viable: allows at most single argument '__off', but 2 arguments were provided
    _LIBCPP_INLINE_VISIBILITY fpos(streamoff __off = streamoff()) : __st_(), __off_(__off) {}
                              ^
/opt/mingw-llvm-toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/string:532:28: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided
class _LIBCPP_TEMPLATE_VIS fpos
                           ^
/opt/mingw-llvm-toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/string:532:28: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 2 were provided

...

/opt/mingw-llvm-toolchain/llvm-mingw/boost_1_67_0/boost/iostreams/positioning.hpp:96:16: error: no member named 'seekpos' in 'std::__1::fpos<int>'
    return pos.seekpos();
           ~~~ ^

My toolchain is as follows :

• Linux host
• clang / libc++ MinGW cross-compiler (e.G. clang is a linux binary which creates windows executables with the mingw API) : basically this : https://github.com/mstorsjo/llvm-mingw

Any idea of what's going on ? I suppose that BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS is defined when it shouldn't ?

[jcelerier]

I solve it in my own code by doing

#include <boost/iostreams/detail/config/fpos.hpp>
#if defined(BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS)
#undef BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS
#endif

beforehand but I guess there should be a better way. Certainly the check should look for more than _YVALS now, since mingw includes yvals.h.

[jeking3]

The CI builds on AppVeyor pass, but they use the following build command (it is mingw inside msys2): ./b2 libs/iostreams toolset=gcc-mingw32 cxxstd=03 address-model=32 variant=release,debug -j3

I was going to suggest replacing the block you identified with the following:

#include <boost/predef/library/std.h>
#if (BOOST_LIB_STD_DINKUMWARE)
...

However after looking at the detection there, it relies on the same check for _YVALS. Copying @grafikrobot since the Dinkumware detection probably needs to omit MinGW platforms. In fact, I'd suggest looking at the checks in iostreams to make sure we're not missing anything else in predef.

[jcelerier]

The CI builds on AppVeyor pass, but they use the following build command (it is mingw inside msys2):

hi, compared to this configuration I'm building with clang and libc++, not gcc and libstdc++ - I guess this could be the difference ?

[SquallATF]

@jcelerier append && !defined(_LIBCPP_VERSION) at https://github.com/boostorg/iostreams/blob/15e72589733152755ed0778b0bbee9f1c9bdcc84/include/boost/iostreams/detail/config/fpos.hpp#L29

[tomay3000]

I have the same problem when compiling v1.72 using the same toolchain https://github.com/mstorsjo/llvm-mingw under Windows 7 x64 https://github.com/boostorg/build/issues/557

So I have to apply the patch and see!

BTW, what command lines u used to bootstrap and compile it?

TIA.

[Gei0r]

I face the same problem in v1.74 using clang and libc++ on Windows. https://github.com/boostorg/iostreams/pull/106 fixes it. Please merge it.