Re: [boost] Problems building Boost libraries for Windows Store when C++/CX is involved

Subject: Re: [boost] Problems building Boost libraries for Windows Store when C++/CX is involved
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-10-05 16:21:50

On 05.10.2015 22:44, Vladimir Prus wrote:
> On 05-Oct-15 6:53 PM, Andrey Semashev wrote:
>> On 05.10.2015 12:48, Mikael Olenfalk wrote:
>>> Hi,
>>>
>>> I am working on porting the boost libraries we depend on to winrt, most
>>> porting is rather straightforward (basically switch from win32 apis
>>> which
>>> are 20 years old to apis which are 15 years old :D ).
>>>
>>> However I have hit a bit of a problem when compiling Boost.Log.
>>> Boost.Log
>>> depends on Boost.Asio which uses C++/CX to call some of the newer Store
>>> APIs (Windows::Networking and friends).
>>>
>>> When I build I get these errors:
>>>
>>> compile-c-c++
>>> ..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj
>>>
>>> dump_ssse3.cpp
>>> ..\..\..\libs\log\src\dump_ssse3.cpp: fatal error C1107: could not find
>>> assembly 'platform.winmd': please specify the assembly search path using
>>> /AI or by setting the LIBPATH environment variable
>>
>> dump_ssse3.cpp (as well as other dump*.cpp files) are not related to
>> Boost.ASIO or networking in general. I don't think
>> the error above is related to Boost.ASIO.
>>
>> That said, I'm quite far from modern Windows development currently and
>> I don't understand the error. I have no idea what
>> an assembly or platform.winmd in particular is. The code in
>> dump_ssse3.cpp uses compiler intrinsics to generate
>> SSSE3-optimized x86 code, so maybe there's some limitation about using
>> the intrinsics.
>
> Andrey,
>
> I don't believe this error has anything to do with Boost.Log or content
> of dump_sse3.cpp at all - it's emitted pretty
> much any time when cl.exe is passed /ZW switch (which asks to 'link' to
> Windows Runtime things), and these
> Windows Runtime things are not found in search paths.

Ok, thanks.

If this is a problem with VS environment setup scripts, has this issue 
been reported to MS Connect?