Boost.Context fails to build using MinGW

[anonymous]

Boost.Context (1.51.0) fails to build using MinGW on Windows 7 Pro 32-bit. Here's what I did:

1. Ran "bootstrap.bat gcc". Completed successfully.
2. Invoked bjam using the following command line:

bjam -d+2 -j4 -q variant=debug,release link=static threading=multi toolset=gcc runtime-link=shared cxxflags="-D__int64=\"long long int\" -DBOOST_REGEX_MATCH_EXTRA " -sICU_PATH=C:/Tools/ICU/49.1.1/MinGW -sICU_LINK="-LC:/Tools/ICU/49.1.1/MinGW/lib" linkflags="-LC:/Tools/ICU/49.1.1/MinGW/lib -lsicuuc -lsicuin -lsicudt"

The output I get is

Building the Boost C++ Libraries.


Performing configuration checks

    - 32-bit                   : yes
    - x86                      : yes
    - has_icu builds           : yes
    - iconv (libc)             : no
    - iconv (separate)         : no
    - icu                      : yes
    - gcc visibility           : yes
    - long double support      : yes
warning: No python installation configured and autoconfiguration
note: failed.  See http://www.boost.org/libs/python/doc/building.html
note: for configuration instructions or pass --without-python to
note: suppress this message and silently skip all Boost.Python targets

Component configuration:

    - chrono                   : building
    - context                  : building
    - date_time                : building
    - exception                : building
    - filesystem               : building
    - graph                    : building
    - graph_parallel           : building
    - iostreams                : building
    - locale                   : building
    - math                     : building
    - mpi                      : building
    - program_options          : building
    - python                   : building
    - random                   : building
    - regex                    : building
    - serialization            : building
    - signals                  : building
    - system                   : building
    - test                     : building
    - thread                   : building
    - timer                    : building
    - wave                     : building

Jamfile</C:/Tools/Boost/1.51.0/libs/context/build>.masm bin.v2\libs\context\build\gcc-mingw-4.7.1\debug\address-model-32\architecture-x86\link-static\threading-multi\asm\fcontext_i386_ms_pe_masm.o

    ml /c /Fo"bin.v2\libs\context\build\gcc-mingw-4.7.1\debug\address-model-32\architecture-x86\link-static\threading-multi\asm\fcontext_i386_ms_pe_masm.o" "libs\context\src\asm\fcontext_i386_ms_pe_masm.asm"

'ml' is not recognized as an internal or external command,
operable program or batch file.
...skipped <pbin.v2\libs\context\build\gcc-mingw-4.7.1\debug\link-static\threading-multi>libboost_context-mgw47-mt-d-1_51.a(clean) for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\debug\address-model-32\architecture-x86\link-static\threading-multi>asm\fcontext_i386_ms_pe_masm.o...
...skipped <pbin.v2\libs\context\build\gcc-mingw-4.7.1\debug\link-static\threading-multi>libboost_context-mgw47-mt-d-1_51.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\debug\address-model-32\architecture-x86\link-static\threading-multi>asm\fcontext_i386_ms_pe_masm.o...
...skipped <pstage\lib>libboost_context-mgw47-mt-d-1_51.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\debug\link-static\threading-multi>libboost_context-mgw47-mt-d-1_51.a...
Jamfile</C:/Tools/Boost/1.51.0/libs/context/build>.masm bin.v2\libs\context\build\gcc-mingw-4.7.1\release\address-model-32\architecture-x86\link-static\threading-multi\asm\fcontext_i386_ms_pe_masm.o

    ml /c /Fo"bin.v2\libs\context\build\gcc-mingw-4.7.1\release\address-model-32\architecture-x86\link-static\threading-multi\asm\fcontext_i386_ms_pe_masm.o" "libs\context\src\asm\fcontext_i386_ms_pe_masm.asm"

'ml' is not recognized as an internal or external command,
operable program or batch file.
...skipped <pbin.v2\libs\context\build\gcc-mingw-4.7.1\release\link-static\threading-multi>libboost_context-mgw47-mt-1_51.a(clean) for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\release\address-model-32\architecture-x86\link-static\threading-multi>asm\fcontext_i386_ms_pe_masm.o...
...skipped <pbin.v2\libs\context\build\gcc-mingw-4.7.1\release\link-static\threading-multi>libboost_context-mgw47-mt-1_51.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\release\address-model-32\architecture-x86\link-static\threading-multi>asm\fcontext_i386_ms_pe_masm.o...
...skipped <pstage\lib>libboost_context-mgw47-mt-1_51.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.7.1\release\link-static\threading-multi>libboost_context-mgw47-mt-1_51.a...
...failed updating 2 targets...

The output only contains the errors about Boost.Context because I attempted to rebuild using the same command line.

[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.

[anonymous]

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]

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).

[olli]

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]

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]

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]

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]

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]

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]

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

[anonymous]

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

[anonymous]

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

[jmartinez@…]

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

[olli]

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]

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

[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."

[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

[bkline@…]

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]

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

[olli]

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.

[slowriot <riot@…>]

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.

[Daniel Starke <daniel.f.starke@…>]

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]

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

[olli]

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]

new commit 934dee6f7e185f72b4b09532e575131f7492ef11 pushed to branch develop