Boost C++ Libraries: Ticket #7262: Boost.Context fails to build using MinGW

anonymous — Wed, 19 Sep 2012 09:09:38 GMT

you need to add the path to ml in your system PATH variable. Its located in your C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin folder.

anonymous — Thu, 20 Sep 2012 21:19:04 GMT

Replying to anonymous:

you need to add the path to ml in your system PATH variable. Its located in your C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin folder.

You need to have Visual Studio in order to compile using MinGW?

anonymous — Thu, 20 Sep 2012 21:24:01 GMT

Context should detect the presence of its needed build binaries and self-disable if it's unable to compile in the environment with a meaningful error. You shouldn't have to crawl through each individual component library's docs in order to successfully complete the overall boost build (though it should point out that it's not being built and why).

component changed; owner set

viboes — Thu, 03 Jan 2013 16:57:32 GMT

owner set to olli
component Building Boost → context

status changed; resolution set

olli — Thu, 03 Jan 2013 17:18:40 GMT

status new → closed
resolution → wontfix

As described boost.context requires an assembler tool on the platform.

Provide MASM/MASM64 (ml.exe/ml64.exe) in the search path - the assembler tool is provided by the SDK - use the MSVC command prompt for compiling boost with bjam/b2.

anonymous — Thu, 07 Feb 2013 05:39:40 GMT

I'm new to boost. I just had the same problem and agree with the anonymous user saying boost/boost context should report a meaningful error.

The error I got was couldn't find ml64 which meant nothing to me. Infact it was hard to see ml64 in the whole error message. When I eventually noticed, I had to google what ml64 actually was and then work out how to get it. olli's description is fine, but how can it not be better for the build environment to offer olli's description than just to get a file not found error. Seems like a lazy respone to me. Boost checks many other things, why not that a valid assembler exists in the path.

olli — Thu, 07 Feb 2013 06:43:03 GMT

Replying to anonymous:

The error I got was couldn't find ml64 which meant nothing to me. Infact it was hard to see ml64 in the whole error message. When I eventually noticed, I had to google what ml64 actually was and then work out how to get it.

In the documentation I wrote: 'Boost.Context must be built for the particular compiler(s) and CPU architecture(s)s being targeted. Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, MASM for Windows/x86 systems and ARMasm for Windows/arm systems. ... MASM64 (ml64.exe) is a part of Microsoft's Windows Driver Kit. '

olli's description is fine, but how can it not be better for the build environment to offer olli's description than just to get a file not found error. Seems like a lazy respone to me. Boost checks many other things, why not that a valid assembler exists in the path.

AFAIK boost will move from bosot.build to cmake - maybe things will become better. Please note that not all toolsets contain an assembler.

anonymous — Fri, 22 Feb 2013 00:13:42 GMT

Replying to olli:

Replying to anonymous:

The error I got was couldn't find ml64 which meant nothing to me. Infact it was hard to see ml64 in the whole error message. When I eventually noticed, I had to google what ml64 actually was and then work out how to get it.

In the documentation I wrote: 'Boost.Context must be built for the particular compiler(s) and CPU architecture(s)s being targeted. Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, MASM for Windows/x86 systems and ARMasm for Windows/arm systems. ... MASM64 (ml64.exe) is a part of Microsoft's Windows Driver Kit. '

Can't you at least try to port the MASM to GNU AS? It is rather short-sighted to provide Visual Studio-only solution when a lot of people use gcc/GNU AS on windows. Look at libcoro if you need to see what is needed for this to work, it would see that you can share much of the POSIX GNU AS. I think code in Boost that provides a Win MASM but not Win GNU AS is against software freedom.

olli — Fri, 22 Feb 2013 07:57:36 GMT

Replying to anonymous:

Can't you at least try to port the MASM to GNU AS?

no - I will support only one assembler on each platform

It is rather short-sighted to provide Visual Studio-only solution when a lot of people use gcc/GNU AS on windows.

MASM is an assembler tool - it has nothing to do with Visual Studio. MASM is the standard assembler on x86 Windows.

Look at libcoro if you need to see what is needed for this to work, it would see that you can share much of the POSIX GNU AS.

libcoro is implemented for C - it has never to support C++-exceptions for instance.

I think code in Boost that provides a Win MASM but not Win GNU AS is against software freedom.

MASM is free available and GNUS AS is used by boost.context on POSIX platforms.

You should ask the MinGW developers to get their software correct (for instance linker used by MinGW does not understand the EXPORT keyword in the object files generated by MASM).

anonymous — Sat, 02 Mar 2013 21:55:09 GMT

Just installed Boost for the first time and found I had this problem. Googled it and found this ticket. Then Googled "MASM" and found you can download it direct from Microsoft see http://www.microsoft.com/en-gb/download/details.aspx?id=12654 You then need to use WinRar or 7Zip to extract the setup.exe from the file. Then extract the cab file from setup.exe. Then extract the file that starts FL_ml.... and rename it to ml.exe. Put it somewhere in your path then boost should build without errors.

anonymous — Sat, 02 Mar 2013 22:49:48 GMT

MinGW's linker is broken (keyword EXPORT unknown) - boost.context will not compile

status changed; resolution deleted

anonymous — Tue, 05 Mar 2013 15:02:36 GMT

status closed → reopened
resolution wontfix

Replying to olli:

Replying to anonymous:

Can't you at least try to port the MASM to GNU AS?

no - I will support only one assembler on each platform

This is not helpful. Fedora (and other Linux distributions) provide an extensive cross compilation environment for windows. We've been providing boost for close to 5 years without problem. Now comes boost::context which suddenly requires masm to build. masm is not acceptable to us, because it does not work in a cross compilation environment (we even had ppc builders), and because of its license.

So I've ported the windows asm files to gas. It's not exactly hard, and I don't see a reason why they could not be added to boost. See the attached patch.

I've tested the example in the manual both under 32 and 64bit windows, it works. (well, the manual code has bugs - it does not allocate sp2, and guarded_stack_allocator does not seem to exist)

Here's the fedora mingw build with the patch: http://koji.fedoraproject.org/koji/buildinfo?buildID=399464

attachment set

anonymous — Tue, 05 Mar 2013 15:05:21 GMT

attachment → boost-mingw.patch

boost::context compilation for MinGW (gas port of masm files)

jmartinez@… — Sun, 17 Mar 2013 14:24:51 GMT

Your patch is working great for me on MinGW32-gcc-4.7.2, I propose the inclusion of the patch!

status, severity changed; resolution set

olli — Sun, 17 Mar 2013 16:08:32 GMT

status reopened → closed
resolution → wontfix
severity Problem → Not Applicable

1.) the original bug report was invalid because MASM was not in the search path

2.) I'll not add a workaround because MINGWs linker is broken

notice that MASM generates correct object files - with other linkers the library works even if MASM is used

Steven Watanabe — Wed, 09 Apr 2014 20:19:01 GMT

This patch is out-dated. The ABI for Boost.Context has changed.

bkline@… — Sun, 04 May 2014 21:42:38 GMT

Replying to olli:

MASM is an assembler tool - it has nothing to do with Visual Studio.

Then why, when I download MASMsetup.exe from Microsoft and try to run it do I get the following error message?

"Microsoft Visual C++ Express Edition 2005 required."

anonymous — Mon, 05 May 2014 06:00:13 GMT

Replying to bkline@…:

Replying to olli:

MASM is an assembler tool - it has nothing to do with Visual Studio.

Then why, when I download MASMsetup.exe from Microsoft and try to run it do I get the following error message?

"Microsoft Visual C++ Express Edition 2005 required."

you should ask Microsoft

bkline@… — Mon, 05 May 2014 10:51:22 GMT

Replying to anonymous:

Replying to bkline@…:

Replying to olli:

MASM is an assembler tool - it has nothing to do with Visual Studio.

Then why, when I download MASMsetup.exe from Microsoft and try to run it do I get the following error message?

"Microsoft Visual C++ Express Edition 2005 required."

you should ask Microsoft

Let me rephrase my question: How can you claim MASM has nothing to do with Visual Studio if it can't be installed without Visual C++?

anonymous — Thu, 15 May 2014 23:01:02 GMT

This library is broken. It fails to detect the environment correctly. Boost build system should check dependencies correctly, like regex.

olli — Fri, 16 May 2014 06:10:14 GMT

Replying to anonymous:

This library is broken. It fails to detect the environment correctly. Boost build system should check dependencies correctly, like regex.

Strange - the regerssion tests at http://www.boost.org/development/tests/develop/developer/context.html show that MinGW pass the tests.

Tue, 11 Nov 2014 20:34:13 GMT

I've just encountered this issue, and having spent all evening battling with it, I wanted to post to say there is a solution.

The problem is that MASM 6 generates EXPORT symbols in the binary which MinGW's binutils cannot parse.

The solution is simply to use MASM 8. You can get this from Microsoft's site (I can't post a link or this will get flagged as spam) - it does bitch about needing to have Visual C installed but you can just bypass this by manually extracting the nested contents with WinRAR or a similar tool, and renaming the resulting file to ml.exe.

Thu, 21 Jan 2016 19:00:56 GMT

I am trying to cross compile boost on Linux for MinGW.
What is the supposed solution if only MASM is supported?
If there is only one assembler per target platform I expect that this assembler is available on all primary hosts. Though, this is only my opinion.

olli — Fri, 22 Jan 2016 07:50:46 GMT

I'm too busy at the moment - but you are welcome to provide a patch.

olli — Fri, 22 Jan 2016 08:16:27 GMT

If you look into context/src/asm you should see files for GNU AS:
jump_i386_ms_pe_gas.asm/make_i386_ms_pe_gas.asm jump_x86_64_ms_pe_gas.asm/make_x86_64_ms_pe_gas.asm
if you build with --toolset=gcc one set of the above should be selected. cross compiling is special because boost.build has to build boost.context for Windows (e.g. os.name has to return 'NT') othersie the build will fail.
You can check the values of the build properties if you apply --debug-building at b2/bjam command line.

for instance the required build properties look like: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe

anonymous — Fri, 22 Jan 2016 19:23:52 GMT

new commit 934dee6f7e185f72b4b09532e575131f7492ef11 pushed to branch develop