Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler <t...@rothenpieler.org> a écrit : >On 17.03.2024 18:37, Rémi Denis-Courmont wrote: >> >> >> Le 17 mars 2024 10:29:39 GMT-07:00, Andreas Rheinhardt >> <andreas.rheinha...@outlook.com> a écrit : >>> Rémi Denis-Courmont: >>>> >>>> >>>> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer <jamr...@gmail.com> a >>>> écrit : >>>>>> Seems the conflict comes from >>>>>> https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287 >>>>>> and >>>>>> https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6 >>>>>> >>>>>> Perhaps you could also try asking libbluray if they could use an internal >>>>>> prefix. Otherwise you might need to do a rename of that function on >>>>>> ffmpeg's side. >>>>> >>>>> libbluray 100% needs to either prefix it, or hid it so it's not exported. >>>>> It's a library, so it should not be exporting such simple and short >>>>> unprefix named symbols. >>>> >>>> AFAICT, FFmpeg is just as guilty as Libbluray there. To support static >>>> linking, all non-static symbols should be name-spaced, and here both >>>> FFmpeg and libbluray are failing, and thus both should be fixed IMO. >>>> >>> >>> You forgot that FFmpeg's dec_init is in fftools/the executable, whereas >>> libbluray's is in the library. >> >> Oh well then it's 100% a problem with FFmpeg, or with the build system used >> by OP (Possibly a problem with Apple's tools). A static library being >> imported is not supposed to be able to cause symbol conflicts. > >A static library, as opposed to a shared one, has no concept of private >symbols. >The symbol already is not exported by libbr, but in the case of static >linking, there is no distinction between exported and hidden symbols.
Yes. But an symbol from an import library is not supposed to conflict with a symbol from the executable (or library) being linked. Hence this looks like a bug in the FFmpeg build system (or whatever OP did with it). Of course libbr should not leak unprefixed symbols regardless, but that's *not* the root cause. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
