On Sunday July 12 2026 21:41:25 Dennis Mungai wrote:
Hi,
>To answer your question directly: it is exclusively the presence of the
>-flto argument that suppresses those symbols. None of the other flags in
>your invocation are responsible.
Pity, I was hoping there was a flag controlling visibility that I was
overlooking. The invocation comes from the build log otherwise, so it's what
FFmpeg's build system emits for this file.
>The "Build Trick" You Likely Used in April:
>You mentioned that you suspect you figured out an mlpdsp_init build trick
>back in April and forgot it.
The trick I might have used would have been to identify the file concerned,
rebuild that without LTO, remove libavcodec.{a,so*} and relaunch the build,
because,
>Does your framework have a quick way to isolate CFLAGS for a specific
>object file to test this?
It probably could, but I'll have to admit that I wouldn't know how to do this
myself, without patching a Makefile.in or something of the sort.
> * Source Patching: You might have patched mlpdsp_init.c to explicitly tag
>the inline assembly operands or the referencing arrays with
>__attribute__((used)), forcing LLVM to keep them alive during the LTO pass.
That actually seems like the proper and most future-proof fix to me, because I
can hardly be the only person being bitten by this.
FWIW, the fact that I use a reproducible-build framework is not at all
*responsible* here. I only mentioned that I do to underline that nothing had
changed in my build parameters beyond the updated binutils.
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.
R.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
