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

[Måns Rullgård]

D <lessen42 at gmail.com> writes:

> 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.
>
>
> diff --git a/configure b/configure
> index 479105c..6195d81 100755
> --- a/configure
> +++ b/configure
> @@ -1262,6 +1262,7 @@ case $target_os in
>          SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME).$(LIBMAJOR)$(SLIBSUF)'
>          FFSERVERLDFLAGS=-Wl,-bind_at_load
>          objformat="macho"
> +        enabled x86_64 && objformat="macho64"
>          ;;
>      mingw32*)
>          target_os=mingw32
> @@ -1561,6 +1562,7 @@ EOF
>      enabled_all x86_64 shared && append YASMFLAGS "-DPIC"
>      case "$objformat" in
>          elf) enabled debug && append YASMFLAGS "-g dwarf2" ;;
> +        macho64)              append YASMFLAGS "-DPIC -DPREFIX" ;;
>          *)                    append YASMFLAGS "-DPREFIX"  ;;
>      esac
>      check_yasm "pabsw xmm0, xmm0" && enable yasm

Can someone confirm that this fixes the problem?  If so, patch OK.

-- 
M?ns Rullg?rd
mans at mansr.com