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

[Timo Rothenpieler <timo@rothenpieler.org>]

On 18.03.2024 01:32, Rémi Denis-Courmont wrote:
> 
> 
> Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler <timo@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@outlook.com> a écrit :
>>>> Rémi Denis-Courmont:
>>>>>
>>>>>
>>>>> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer <jamrial@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.
Again: static linking has no concept of public and private symbols. It's 
just pulling in object files relatively mindlessly.

> 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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".