ffmpeg: building-for-macos-but-l

参考building-for-macos-but-linking-in-object-file-built-for-free-standing

ld: warning: building for macOS, but linking in object file (~/dby-paas-ios-sdk/DbyPaas_Core/third_party_osx/FFmpeg/lib/libswscale.a(input.o)) built for free standing
ld: warning: building for macOS, but linking in object file (~/dby-paas-ios-sdk/DbyPaas_Core/third_party_osx/FFmpeg/lib/libswscale.a(scale.o)) built for free standing
ld: warning: building for macOS, but linking in object file (~/dby-paas-ios-sdk/DbyPaas_Core/third_party_osx/FFmpeg/lib/libavutil.a(imgutils.o)) built for free standing
ld: warning: building for macOS, but linking in object file (~/dby-paas-ios-sdk/DbyPaas_Core/third_party_osx/FFmpeg/lib/libswscale.a(output.o)) built for free standing
...

原因是 clang 会在生成的 Mach-O 文件的 load command 区域，加入 target platform, system version and SDK version 等参数。 ffmpeg 里面为了为了代码效率，有一些汇编代码。编译这些汇编代码，用的不是 clang ， 而是 YASM、NASM。 这些汇编器编译的Mach-O 文件里面，缺少这些参数，链接的时候就出现这些警告了。

The problem is with .asm files in the FFmpeg build.

Apple Clang embeds a special load command in the object files with the target platform, system version and SDK version which it takes from -target or -mmacosx-version-min or some similar command line argument.

Linker then checks such load commands in all object files being linked and warns if it couldn't find such command or if it detects incompatibility.

Most of other compilers don't know about that load command and give no way to output it in the object file. Problems were seen at least in YASM (it manifests in this issue), in D and Go compilers, in Crystal.

Unfortunately I couldn't find a workaround to build good objects for asm sources in FFmpeg or to disable that warnings. I've created an issue for YASM but this is a long shot - first you need this feature in YASM, then you need a way to pass the required argument to FFmpeg build for the asm sources.