Subject: Re: [Boost-build] 1.53.00 - masm ml options not honored??
From: Jeff Flinn (jeffrey.flinn_at_[hidden])
Date: 2013-10-03 14:59:28
On 10/3/2013 2:41 PM, Vladimir Prus wrote:
> 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.
Yes the above sets /safeseh when explicitly specifying address-model=32
on the command line. What does that tell you?
>> 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 '='.
asmflags=/safeseh (the / is required) works with the original boost
context jamfile.
Thanks, Jeff