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

David Conrad lessen42
Tue Dec 16 00:21:16 CET 2008


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.



More information about the ffmpeg-devel mailing list