[FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

[Rémi Denis-Courmont]

Le 17 mars 2024 18:21:23 GMT-07:00, Timo Rothenpieler <timo at rothenpieler.org> a écrit :
>On 18.03.2024 01:32, Rémi Denis-Courmont wrote:
>> 
>> 
>> Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler <timo at 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.rheinhardt at outlook.com> a écrit :
>>>>> Rémi Denis-Courmont:
>>>>>> 
>>>>>> 
>>>>>> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer <jamrial at 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).
>
>How would it be a bug in the ffmpeg build system?
>What is it supposed to do? When statically linking, there simply is nothing that can be done about it.

Obviously not. Imported libraries are only there to resolve missing symbols.  They don't and can't cause duplicate symbol errors when the build system and tools work correctly.

>Again: static linking has no concept of public and private symbols. It's just pulling in object files relatively mindlessly.

You're confusing visibility, a notion specific to dynamic linking, with needed, undefined and duplicate symbols, which do exist regardless of static vs dynamic linking.

This is clearly a bug in however OP is building FFmpeg. I don't know if that's a bug in FFmpeg proper or something else in OP's setup, but libbr is just the canary exposing a bug here.

>
>> Of course libbr should not leak unprefixed symbols regardless, but that's *not* the root cause.
>
>Yes, as long as they claim to support static linking, having such symbols is definitely an issue on their side.

Absolutely not. The issue on their side is that they implicitly rely on `-Bsymbolic` type behaviour which can't work with static linkage. That does not cause the linkage error here which **cannot** be libbr bug.


>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel at ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".