Re: [Boost-build] 1.53.00 - masm ml options not honored??

Subject: Re: [Boost-build] 1.53.00 - masm ml options not honored??
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-10-03 14:41:27

On 03.10.2013 22:30, Jeff Flinn wrote:
> On 10/3/2013 2:12 PM, Vladimir Prus wrote:
>> On 03.10.2013 21:38, Jeff Flinn wrote:
>>> On 10/3/2013 11:47 AM, Vladimir Prus wrote:
>>>> On 03.10.2013 18:01, Jeff Flinn wrote:
>>>>> msvc.compile.asm
>>>>> bin.v2\libs\context\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\asm\make_i3
>>>>>
>>>>>
>>>>> 86_ms_pe_masm.obj
>>>>>   Assembling: libs\context\src\asm\make_i386_ms_pe_masm.asm
>>>>> libs\context\src\asm\make_i386_ms_pe_masm.asm(45) : warning
>>>>> A4024:directive ignored without /safeseh switch
>>>>
>>>> msvc.compile.asm is standard assembler action, so it's not surprising it
>>>> does not have /safeseh switch.
>>>>
>>>> Looking at Jamfile, I see this:
>>>>
>>>> alias asm_context_sources
>>>>     : asm/make_i386_ms_pe_masm.asm
>>>>       asm/jump_i386_ms_pe_masm.asm
>>>>       dummy.cpp
>>>>     : <address-model>32
>>>>       <architecture>x86
>>>>       <binary-format>pe
>>>>       <target-os>windows
>>>>       <toolset>msvc
>>>>     ;
>>>>
>>>> which seems to be the most specific version of asm_context_sources when
>>>> you use msvc toolset. Maybe you need
>>>
>>> So in the boost context Jamfile.v2, Oliver has
>>> (and I added the /safeseh argument)
>>>
>>> actions masm
>>> {
>>>      ml /safeseh /c /Fo"$(<)" "$(>)"
>>> }
>>>
>>> ....
>>>
>>> alias asm_context_sources
>>>     : [ make asm/make_i386_ms_pe_masm.o : asm/make_i386_ms_pe_masm.asm
>>> : @masm ]
>>>       [ make asm/jump_i386_ms_pe_masm.o : asm/jump_i386_ms_pe_masm.asm
>>> : @masm ]
>>>       dummy.cpp
>>>     : <address-model>32
>>>       <architecture>x86
>>>       <binary-format>pe
>>>       <target-os>windows
>>>     ;
>>>
>>> So are you saying this is not applicable when building with msvc
>>> because the more specific ...<toolset>msvc takes precendence?
>>
>> Yes. If there are several matching alternatives, the one with longest
>> list of requirements is picked. The above appears to have
>> 4 matching properties, the other one 5.
>>
>>
>>> Are the above portions even useful?
>>
>> I don't know enough to answer that - I wish there was a comment as to
>> the purpose of that. Maybe, it's trying
>> to assemble files using "ml" tool on Windows, even for non-msvc
>> toolchain? I don't know whether that's good
>> idea.
>>
>>>> some <toolset>msvc:<asmflags>/safeseh somewhere in that Jamfile, like on
>>>> top level?
>>>
>>> Is this what you mean by "like on top level"?
>>>
>>> project boost/context
>>>      : source-location ../src
>>>      : requirements
>>>        <os>SOLARIS:<define>_XOPEN_SOURCE=1
>>>        <os>SOLARIS:<define>_XOPEN_SOURCE_EXTENDED=1
>>>        <toolset>msvc:<asmflags>/safeseh
>>>
>>> Indeed /safeseh is being propagated. Unfortunately /safeseh should
>>> only be used with 32bit builds and the above generates warnings for
>>> 64bit. How can this be specified for 32bit msvc only?
>>
>> Try:
>>
>>      <toolset>msvc,<address-model>32:<asmflags>/safeseh
>
> project boost/context
>      : source-location ../src
>      : requirements
>        <os>SOLARIS:<define>_XOPEN_SOURCE=1
>        <os>SOLARIS:<define>_XOPEN_SOURCE_EXTENDED=1
>        <toolset>msvc,<address-model>32:<asmflags>/safeseh
>      : usage-requirements
>        <link>shared:<define>BOOST_CONTEXT_DYN_LINK=1
>      ;
>
>
> Neither 32 or 64 builds propagate the /safeseh flag. Other ideas?

Can you try address-model=32 explicitly on the command line? It's not a solution, but a step.

> Hmm, is there a way to pass asmflags via the build command line?

Seems so:

        http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html

Just separate 'asmflags' and the value with '='.

- Volodya

>
> Thanks, Jeff
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build