Re: [Linux] libavcodec/libavcodec.so: undefined symbol: ff_mlp_iirorder_{0,1,2,3,4} with --enable-lto

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]