Modify

Ticket #7262 (closed Bugs: wontfix)

Opened 3 years ago

Last modified 10 months ago

Boost.Context fails to build using MinGW

Reported by: anonymous Owned by: olli
Milestone: To Be Determined Component: context
Version: Boost 1.51.0 Severity: Not Applicable
Keywords: context mingw Cc:

Description

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.

Attachments

boost-mingw.patch Download (35.0 KB) - added by anonymous 2 years ago.
boost::context compilation for MinGW (gas port of masm files)

Change History

comment:1 follow-up: ↓ 2 Changed 3 years ago by 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.

comment:2 in reply to: ↑ 1 Changed 3 years ago by 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?

comment:3 Changed 3 years ago by 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).

comment:4 Changed 3 years ago by viboes

  • Owner set to olli
  • Component changed from Building Boost to context

comment:5 Changed 3 years ago by olli

  • Status changed from new to closed
  • Resolution set to 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.

comment:6 follow-up: ↓ 7 Changed 3 years ago by 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.

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 3 years ago by 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.

Last edited 3 years ago by olli (previous) (diff)

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 3 years ago by 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.

comment:9 in reply to: ↑ 8 ; follow-ups: ↓ 12 ↓ 16 Changed 3 years ago by 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).

comment:10 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by anonymous

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

comment:12 in reply to: ↑ 9 Changed 2 years ago by anonymous

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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

Changed 2 years ago by anonymous

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

comment:13 Changed 2 years ago by jmartinez@…

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

comment:14 Changed 2 years ago by olli

  • Status changed from reopened to closed
  • Resolution set to wontfix
  • Severity changed from Problem to 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

comment:15 Changed 17 months ago by steven_watanabe

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

comment:16 in reply to: ↑ 9 ; follow-up: ↓ 17 Changed 16 months ago by 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."

comment:17 in reply to: ↑ 16 ; follow-up: ↓ 18 Changed 16 months ago by 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

comment:18 in reply to: ↑ 17 Changed 16 months ago by 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++?

comment:19 follow-up: ↓ 20 Changed 16 months ago by anonymous

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

comment:20 in reply to: ↑ 19 Changed 16 months ago by 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.

comment:21 Changed 10 months ago by 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.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.