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. To be clear, the poor choice of symbol name in libbluray might cause Libbluray to misbehave at runtime (due to its own fault), but not to fail linking. In other words, it's still two bugs, one in each project. _______________________________________________ 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".
