9

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
RopeySim
  • 423
  • 4
  • 11

2 Answers2

15

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 :(

John Preston
  • 166
  • 1
  • 4
  • Great answer thank you! Everything seems to be working so i assume there’s no impact? – RopeySim Nov 30 '19 at 11:32
  • I hope there is no impact. With the appropriate command line argument Apple Clang checks while compiling that no methods unavailable in the target system are used. In case of object files compiled by some other compilers, like YASM, all bets are off, you just hope that they generate code that will run without problems on your target system. I really hope that FFmpeg doesn't use anything very tricky in their asm modules that will cause it not working in some Apple systems. – John Preston Dec 04 '19 at 17:58
  • FYI the default assembler for FFmpeg changed from yasm to nasm in v3.4. I think the most portable solution would be a wrapper that can used with `configure --x86asmexe=` which can invoke yasm/nasm and then edit the resulting object to add the missing macho load commands. – tmm1 Dec 20 '19 at 22:01
  • @tmm1 Thanks for the idea, I tried to implement it in some way and added the result to my answer. – John Preston Nov 05 '20 at 15:34
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?

Jordan
  • 4,133
  • 1
  • 27
  • 43
  • 1
    How to pass the --disable-asm flag to configure in x-code I am unable to find option can you guide with steps – Azad Hussain Oct 25 '20 at 20:37
  • You do not pass it in Xcode: "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." – Jordan Oct 27 '20 at 13:44