Building for macOS, but linking in object file built for free standing

Question

I am building ffmpeg and I get the following error for several files. I am not specifically building with the free standing flag, so cannot see why this is happening. What does it actually mean? Is there a problem with it, or is it an ignorable warning? If there's a problem, does anyone have any idea how to fix it?

Building for macOS, but linking in object file (~/Git/FFmpeg/FFmpegXcode/lib/libavutil.a(imgutils.o)) built for free standing

Answer 1

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.

UPDATE

Starting with Xcode 12 it became a problem, because this warning became an error and it seems there is no way to disable or ignore this. But it looks like I've managed to hackaround that using approach suggested by tmm1. Unfortunately at the current stage it requires a lot of manual work.

1. I've forked yasm and added padding to the output object file for the missing load command. (for building call ./autogen.sh and make)
2. I've forked macho_edit and added a way to append the required load command with a command line invocation. (for building call xcodebuild build -configuration Release -project macho_edit.xcodeproj -target macho_edit)
3. I've created a shell script that wraps invocation of the custom-built yasm and then custom built macho_edit with required arguments (you can set which macos version and sdk version you want to manifest as supported in this script).
4. To build ffmpeg with this wrapper I copy macos_yasm_wrap.sh to the ffmpeg directory and add --x86asmexe=`pwd`/macos_yasm_wrap.sh argument to ./configure call.

This seems to work. The proper way of doing that would be adding correct command line arguments to yasm (like the ones Clang supports) and generating correct load commands in the first place. But I don't have time to do it this way right now :(

Answer 2

I know this question is for macOS, but I was getting this also for iOS and tvOS when building for the simulators (intel archs, not arm). While https://stackoverflow.com/a/59103419/1777839 certainly explains why this is happening, it doesn't provide a "fix".

This isn't a perfect fix, more of a work around, but it helped me out so I wanted to share it in case anyone else comes here with the same problem I had.

When you're building FFmpeg for the iOS or tvOS simulator, if you pass the --disable-asm flag to configure, this will make the linker error go away. Yes, it disables the optimized assembly pieces of FFmpeg for the simulators, but since it still works for ARM devices I wrote it off as being an acceptable solution. While it would be nice to use the same FFmpeg build options for both physical devices and simulators, at the very least this gets it working again.

Another option that worked was using Xcode 10 to build FFmpeg, but then you can't use the iOS/tvOS 13 SDKs (I don't think that really matters though). Besides, who wants to deal with switching Xcode just to compile a library anyways?