[x264-devel] Compiling x264 with Visual Studio 2010 and Intel compiler

[Kovacs Peter]

On 12/10/2014 12:54 PM, Kovacs Peter wrote:
> On 12/9/2014 7:58 PM, BugMaster wrote:
>> On Tue, 09 Dec 2014 13:09:06 +0100, Kovacs Peter wrote:
>>
>>> [1] http://kemuri9.net/dev/x264/other/intel_howto.html
>>>                  Dear Steven,
>>>          thanks for pointing this out. Indeed, the steps in the
>>> referenced     guide still work with this combination of tools
>>> (using this     workaround
>>> https://software.intel.com/en-us/forums/topic/531996).
>>>       However please note that the original purpose of making a VS
>>> project     for it was to facilitate single stepping in the code for
>>> students     who are more familiar with VS. If I'm not mistaken,
>>> compiling with     the Intel compiler using above methods does not 
>>> allow that.
>>>          Best regards,
>>>       Peter
>> It allow single stepping in VS without any problems (at least with VS
>> 2013 here) if you will compile x264 with debugging info:
>>
>> CC=icl ./configure --enable-debug
>>
>> During compilation it will create x264.exe and x264.pdb file with
>> debugging info. After that you can open x264.exe in VS with
>> File/Open/Project/Solution... menu, choose executable running
>> parameters and then debug start debug it as usual. Drag and drop
>> needed source file if you want to set break point beforehand without
>> debugging to there.
> I stand corrected. With --enable-debug, it really generates a .pdb 
> which I can use to break into the code. However, with the current 
> configuration, single stepping is a bit erratic, as some optimizations 
> as still enabled (in x264-snapshot-20141208-2245).
> Changing line 1063 of configure from
> CFLAGS="-O1 -g $CFLAGS"
> to
> CFLAGS="-Od -g $CFLAGS"
> to completely disable optimizations of icl makes it perfect. (-O0 does 
> not work in icl version 15 on windows, see 
> http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Flags_and_manuals)
>
> Thanks for your help,
> Peter
>
One more thing. Using the above toolchain on x86, windows, 32-bit, with 
yasm is enabled, yasm outputs .obj files, while the linker is looking 
for .o files in the end.
This can be fixed by adding --objext=o to ASFLAGS, e.g.:
         ASFLAGS="$ASFLAGS -O2 --objext=o -DARCH_X86_64=0 
-I\$(SRCPATH)/common/x86/"
on line 605 of configure.
I have experienced the same behaviour with both yasm version 1.2 and 
1.3, looks like -o alone is not enough to specify the extension.
Not sure about other platforms.

Best regards,
Peter