[FFmpeg-devel] fft_mmx.asm yasm 64bit build broken

Robert Swain robert.swain
Sat Aug 16 19:31:13 CEST 2008


2008/8/16 D <lessen42 at gmail.com>:
> On Aug 16, 2008, at 11:59 AM, Robert Swain wrote:
>> 2008/8/16 M?ns Rullg?rd <mans at mansr.com>:
>>> vmrsss <vmrsss at gmail.com> writes:
>>>> On 16 Aug 2008, at 15:49, M?ns Rullg?rd wrote:
>>>>>
>>>>> Ask Apple if they can fix the system.  We don't know.
>>>>
>>>> What do you mean? Doesn't look like a Apple problem at all...
>>>>
>>>>> error: macho: sorry, cannot apply 32 bit absolute relocations in 64
>>>>> bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and
>>>>> "dq _foo" for pointers.
>>>
>>> This is an Apple problem.  Since the same code works on the same
>>> hardware under Linux, it follows that it must be an Apple problem if
>>> it doesn't work in MacOS.  In fact, code like this used to work just
>>> fine with older versions of the Apple linker.  Sorry, but you're
>>> barking up the wrong tree.
>>
>> I don't think this is that linker issue about text relocations. The
>> errors are being spewed by yasm, are they not?
>
> Indeed, from yasm's macho-objfmt.c:
>
>  2.2) data referencing in 64 bit mode
>       While ELF allows 32 bit absolute relocations in 64 bit mode, Mach-O
>       does not. Therefore code like
>        lea rbx,[_foo]  ;48 8d 1c 25 00 00 00 00
>        mov rcx,[_bar]  ;48 8b 0c 25 00 00 00 00
>       with a 32 bit address field cannot be relocated into an address
>       >= 0x100000000 (OSX actually uses that).
>
>       Actually, the only register where a 64 bit displacement is allowed in
>       x86-64, is rax as in the example 1).
>
>       A plausible workaround is either classic PIC (like in C), which is in
> turn
>       not implemented in this object format. The recommended was is PC
> relative
>       code (called RIP-relative in x86-64). So instead of the lines above,
> just write:
>        lea rbx,[_foo wrt rip]
>        mov rcx,[_bar wrt rip]
>
> x264 uses -DPIC unconditionally for asm code in the x86_64/macho case.
> Additionally, ffmpeg was using macho rather than macho64 in this case.
>
> The attached patch the ffmpeg build on x86_64/darwin.

Applied.

Rob



More information about the ffmpeg-devel mailing list