On Sun, 12 Jul 2026 at 14:32, René J. V. Bertin via ffmpeg-devel < [email protected]> wrote:
> René J.V. Bertin via ffmpeg-devel wrote: > > > Hi, > > > > Back in April of this year, I rebuilt the then current FFmpeg 8.0.1 with > clang > > 17 and configured with --enable-lto . > > > > For some reason, this is no longer possible, neither with v8.1.2 nor with > > v8.0.1, using the exact same compiler build and FFmpeg configure options > (I > > use a framework of scripts to ensure reproducible builds). > SNIP > > What might I have updated since April that causes the build to fail? I > did > > update `binutils` to 2.46.0 but rolling back to the version I had > installed in > > April (2.43.1) does not seem to fix the issue (at least not when I just > use > > that older `ld` to regenerate libavcodec.so). > > > > Thanks, > > R. > > > Really, no one? > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] Hi René J.V. Bertin, This is a classic mixed-toolchain LTO nightmare, and the binutils update is absolutely the smoking gun here. When you updated to binutils 2.46.0, two critical environmental shifts occurred that broke Clang's ability to link FFmpeg's mixed C-bitcode and native-assembly objects (which is exactly what ff_mlp_iirorder_* are, residing in FFmpeg's nasm/yasm files but referenced by the C-based DSP init code). 1. The bfd-plugins Wipeout: When you build with Clang + LTO, Clang emits LLVM bitcode instead of standard ELF objects. For the GNU binutils suite (ar, nm, ranlib) to read this bitcode, they rely on an LLVM plugin (typically LLVMgold.so) symlinked inside /opt/local/lib/bfd-plugins/ (or your equivalent library path). Installing a new binutils version almost always overwrites or clears this bfd-plugins directory. Without the plugin, ar builds archives with missing bitcode symbol indexes, and nm generates incomplete symbol version scripts ( libavcodec.ver). 2. The Linker Handoff (Gold vs. BFD): Starting with binutils 2.44, ld.gold was deprecated and subsequently phased out. If your previous framework was implicitly falling back to gold for LTO resolution, it is now being forced onto ld.bfd. The BFD linker handles LLVM LTO symbol resolution differently—specifically, it has a known tendency to prematurely discard native assembly objects if the initial pass doesn't see them referenced by a standard ELF object (since it can't natively peer into the bitcode without the plugin). Why GCC 13 Succeeded: GCC doesn't rely on the system-level bfd-plugins directory in the same way. The compiler driver automatically invokes gcc-ar and gcc-nm, which are hardwired to load liblto_plugin.so. This guarantees the symbol tables are built correctly, which is why the GCC pipeline completed successfully. Why the Rollback Failed: Rolling back to binutils 2.43.1 and using the older ld didn't fix the issue because the intermediate build artifacts were already poisoned. The static archives (.a files) or version scripts generated during the build process by the newer ar/nm lacked the necessary bitcode symbols. Linking with an older ld against corrupted intermediate files will still throw undefined reference errors. The Fix: Full LLVM Toolchain Orchestration: For environments where reproducible builds are non-negotiable, relying on system GNU binutils for an LLVM LTO build can prove fragile. To bypass the binutils plugin dependency entirely, you should force FFmpeg's configure script to use the LLVM equivalents. Run a make clean (or git clean -xfd to purge all poisoned intermediate artifacts), and append these explicitly to your FFmpeg configure options: --ar=llvm-ar \ --nm=llvm-nm \ --ranlib=llvm-ranlib \ --extra-ldflags="-fuse-ld=lld" Using lld instead of GNU ld ensures seamless symbol resolution between LLVM bitcode and FFmpeg's native x86 assembly optimizations. Apply the change and retest. _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
