[FFmpeg-devel] [PATCH] Fix shared build on OS X

[David Conrad]

On Dec 15, 2008, at 7:28 PM, Michael Niedermayer wrote:

>
> On Mon, Dec 15, 2008 at 06:21:16PM -0500, David Conrad wrote:
>> On Nov 19, 2008, at 5:12 PM, Michael Niedermayer wrote:
>>
>>> On Wed, Nov 19, 2008 at 01:41:43PM -0500, David Conrad wrote:
>>>> Hi,
>>>>
>>>> Currently compilation on OS X intel with --enable-shared fails with
>>>> (using
>>>> apple gcc 4.0.1)
>>>>
>>>> ffmpeg/libavcodec/i386/cavsdsp_mmx.c: In function
>>>> ?ff_put_cavs_qpel8_mc01_3dnow?:
>>>> ffmpeg/libavcodec/i386/cavsdsp_mmx.c:448: error: can't find a
>>>> register in
>>>> class ?GENERAL_REGS? while reloading ?asm?
>>>>
>>>> This seems to be because gcc decides to use edi for the ADD  
>>>> constant
>>>> instead of memory and borks when the constraints specify its use  
>>>> for
>>>> dstStride.
>>>>
>>>> Attached patch is the minimal needed to fix the build for me, but I
>>>> think
>>>> that all these named registers should probably be replaced with the
>>>> general
>>>> "r". Comments?
>>>
>>> Have you confirmed that
>>> 1. the genrated code is not miscompiled after the patch
>>
>> The only change in the static build is that different registers are
>> used, and the only substantial difference between patched shared and
>> static is that shared doesn't unroll the loop.
>>
>>> 2. svn blame/log why its "D" and not "r" ? i faintly remember this  
>>> was
>>>  like that because of some gcc issue
>>
>> After some searching, all I could find was r1407, which changed mpeg4
>> qpel. I guess h.264 and cavs just copied from that since I can't find
>> anything on the mailing list mentioning this (and I can't find the  
>> old
>> archives from 2003?) But I'd expect that there's plenty of other
>> inline asm in ffmpeg that would be affected by whatever the bug was.
>> Personally I'd like going back to all "r" since the named registers
>> assume Linux's calling convention and Mac OS X uses a different  
>> order.
>>
>>> 3. checked that it still works on other gccs? especially 2.95/3.4/4
>>
>> I couldn't get gcc 2.95 compiled on my linux install, but 3.4, 4.2,
>> and 4.3 work.
>
> ok, then patch ok

Applied.