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

Subject: Re: [Boost-build] 1.53.00 - masm ml options not honored??
From: Jeff Flinn (jeffrey.flinn_at_[hidden])
Date: 2013-10-03 14:30:51

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?

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

Thanks, Jeff