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

René J.V. Bertin wrote on 20260712::22:42:50 re: "Re: [FFmpeg-devel] Re: [Linux] libavcodec/libavcodec.so: undefined symbol: ff_mlp_iirorder_{0,1,2,3,4} with --enable-lto"


>Could I ask you exactly which elements to tag in that file? I'm guessing that for the arrays that would be `static const void * const firtable` and `iirtable` arrays, but for the inline assembly operands I have no idea. I have almost no experience with assembly at all, and here the picture is muddied further by the use of preprocessor macros.

FWIW, I haven't been able to get any effect from using `__attribute__((used))` in any of the configurations where I didn't get a syntax error from using it. In particular, using `static const void * const firtable[9]` (and idem for iirtable) doesn't magically cause the array to appear in `nm -U mlpdsp_init.o`.

I thought that initialising ff_mpl_*order_* in `ff_mlpdsp_init_x86()` should force the compiler to preserve them, but that doesn't work either. 

I did find an article suggesting that one should declare the variables in the C code and then pass them as arguments to the inline assembly:
https://users.ece.utexas.edu/~valvano/EE445M/Arm_Clang_Reference_Guide.pdf (page 344).

That does make sense to me but I have no idea to achieve that.

I'm going to have to check this on Mac, too; if this is an issue with the LLVM toolchain then it should occur on that platform too (probably increasing the urgency).


_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]