On Sunday July 12 2026 15:40:01 Dennis Mungai wrote: Hi,
Thanks for the detailed answer! >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). Yes, this would explain this, though I do have the plugin installed (and `nm` will find and use it). >Why GCC 13 Succeeded: I simply put that off as "designed to work with the rest of standard toolchain" ;) >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. Except that I *did* do a `make clean`, so I'm still not certain what happened there. Even tried deleting the entire directory to be certain no artifacts remained. >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. Doh, I have options in my build framework to use lld, and it never occurred to me to try that... (but see below). As to llvm-ar and family, I already set those (via --ar, --nm AND the AR and NM env. variables) to the llvm versions before invoking the configure script (the RANLIB variable i usually set to /bin/echo as in my experience it is rarely needed and [was] more likely to cause issues). Adding `-fuse-ld=lld` (via LDFLAGS) doesn't solve the issue: ld.lld complains just as much about the same symbols, it just adds the suggestion that that is because of `--no-allow-shlib-undefined`. When I add `--allow-shlib-undefined` to LDFLAGS the build does succeed, but you end up with a libavcodec library that won't load because of these missing symbols. NB: my clang build is configured to use lld by default, so why does the build even use `ld` instead if I don't touch the defaults? Or, why doesn't `--enable-lto` use the entire LLVM toolchain if it detects that clang is being used? R. _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
