[MacPorts] #63443: ffmpeg-4.4_3+gpl2: Build Failed

[MacPorts]

#63443: ffmpeg-4.4_3+gpl2: Build Failed
------------------------+--------------------
  Reporter:  Tommaso93  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.7.1
Resolution:             |   Keywords:
      Port:  ffmpeg     |
------------------------+--------------------

Comment (by msbit):

 I had the same issue while running `port upgrade outdated`, and while I am
 not claiming it's the same for every other report, the cause for mine may
 be relevant.

 When troubleshooting the issue, I had tried to run `nm` on some of the
 output `.o` files, but that had filed with:

 {{{
 dyld: Library not loaded: /opt/local/lib/libffi.7.dylib
   Referenced from: /opt/local/libexec/llvm-10/lib/libLLVM.dylib
   Reason: image not found
 }}}

 which seems to be due to a big migration from `libffi.7.dylib` to
 `libffi.8.dylib` that happened while I'd been neglecting this machine?
 Anyhow, I didn't think much of it, reinstalling with `libffi`, then later
 on performing a rebuild of ffmpeg directly (which worked fine). Poring
 over the output files under
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg/work`
 I discovered one big difference in the `config.log`files, namely:

 {{{
 -check_inline_asm inline_asm_direct_symbol_refs "movl _test, %eax"
 -    1  void foo(void){ __asm__ volatile("movl _test, %eax"); }
 -void foo(void){ __asm__ volatile("movl _test, %eax"); }
 +check_inline_asm inline_asm_direct_symbol_refs "movl test, %eax"
 +    1  void foo(void){ __asm__ volatile("movl test, %eax"); }
 +void foo(void){ __asm__ volatile("movl test, %eax"); }
 -check_inline_asm inline_asm_direct_symbol_refs "movl _test(%rip), %eax"
 +check_inline_asm inline_asm_direct_symbol_refs "movl test(%rip), %eax"
 -    1  void foo(void){ __asm__ volatile("movl _test(%rip), %eax"); }
 +    1  void foo(void){ __asm__ volatile("movl test(%rip), %eax"); }
 }}}

 The big giveaway is the presence of the `_` prefix for the symbol on the
 separate build (post `libffi` installation).

 In the configure script, `nm` is used to determine what the external
 prefix should be for name mangling. If `nm` fails like it did for me, the
 prefix is empty, but if it succeeds the prefix is `_`. This is also used
 to toggle defining `PREFIX` when invoking `nasm`, which ensures that the
 mangled symbols have the same `_` prefix.

 So, finally, looking over just `_ff_butterflies_fixed_sse2`, I've got:

 {{{
 nm ./libavutil/x86/fixed_dsp{,_init}.o | grep ff_butterflies_fixed_sse2$
 0000000000000000 T ff_butterflies_fixed_sse2
                  U _ff_butterflies_fixed_sse2
 }}}

 in the MacPorts ffmpeg work directory and:

 {{{
 nm ./libavutil/x86/fixed_dsp{,_init}.o | grep ff_butterflies_fixed_sse2$
 0000000000000000 T _ff_butterflies_fixed_sse2
                  U _ff_butterflies_fixed_sse2
 }}}

 in the standalone ffmpeg build.

 I'm currently re-running `port upgrade outdated` and the built object file
 has the correct symbol, with mangling:

 {{{
 nm ./libavutil/x86/fixed_dsp{,_init}.o | grep ff_butterflies_fixed_sse2$
 0000000000000000 T _ff_butterflies_fixed_sse2
                  U _ff_butterflies_fixed_sse2
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/63443#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS