[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