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

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

[Helmut K. C. Tessarek]

[-- Attachment #1.1.1: Type: text/plain, Size: 1151 bytes --]

Hello,

It's me again - the dude who compiles ffmpeg for macOS... ;-)

I haven't updated the referenced libbluray, but only compiled ffmpeg the 
way I always do. The last time was about 3 days ago and all was good.

This is the git hash of ffmpeg I tried to compile: b47abd5737

duplicate symbol '_dec_init' in:
     fftools/ffmpeg_dec.o
     /Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

The only code that changed was ffmpeg and libx265, thus I suspect it was 
a change to ffmpeg. I can't really do a git bisect, because this error 
only happens after ffmpeg is compiled at the linker stage, so that would 
take me forever....

However, the dev who did a change related to this would probably know 
right away.

Cheers,
   K. C.


-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Gnattu OC via ffmpeg-devel]

If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic` to LDFLAGS.  During configure you will also need to set `--host-ldflags='-Wl,-ld_classic’`.

> On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek <tessarek@evermeet.cx> wrote:
> 
> Hello,
> 
> It's me again - the dude who compiles ffmpeg for macOS... ;-)
> 
> I haven't updated the referenced libbluray, but only compiled ffmpeg the way I always do. The last time was about 3 days ago and all was good.
> 
> This is the git hash of ffmpeg I tried to compile: b47abd5737
> 
> duplicate symbol '_dec_init' in:
>    fftools/ffmpeg_dec.o
>    /Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
> ld: 1 duplicate symbol for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> The only code that changed was ffmpeg and libx265, thus I suspect it was a change to ffmpeg. I can't really do a git bisect, because this error only happens after ffmpeg is compiled at the linker stage, so that would take me forever....
> 
> However, the dev who did a change related to this would probably know right away.
> 
> Cheers,
>  K. C.
> 
> 
> -- 
> regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> _______________________________________________
> 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".

_______________________________________________
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".

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

[Christopher Degawa]

On Sat, Mar 16, 2024 at 09:08 Gnattu OC via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic`
> to LDFLAGS.  During configure you will also need to set
> `--host-ldflags='-Wl,-ld_classic’`.
>
> > On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek <tessarek@evermeet.cx>
> wrote:
> >
> > Hello,
> >
> > It's me again - the dude who compiles ffmpeg for macOS... ;-)
> >
> > I haven't updated the referenced libbluray, but only compiled ffmpeg the
> way I always do. The last time was about 3 days ago and all was good.
> >
> > This is the git hash of ffmpeg I tried to compile: b47abd5737
> >
> > duplicate symbol '_dec_init' in:
> >    fftools/ffmpeg_dec.o
> >    /Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
> > ld: 1 duplicate symbol for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
> > The only code that changed was ffmpeg and libx265, thus I suspect it was
> a change to ffmpeg. I can't really do a git bisect, because this error only
> happens after ffmpeg is compiled at the linker stage, so that would take me
> forever....
> >
> > However, the dev who did a change related to this would probably know
> right away.
> >
> > Cheers,
> >  K. C.
> >
> >
> > --
> > regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
> > Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> >
> > /*
> >   Thou shalt not follow the NULL pointer for chaos and madness
> >   await thee at its end.
> > */
> > _______________________________________________
> > 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".
>
> _______________________________________________
> 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".



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.
_______________________________________________
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".

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

[Helmut K. C. Tessarek]

[-- Attachment #1.1.1: Type: text/plain, Size: 484 bytes --]

Hello,

On 2024-03-16 10:07, Gnattu OC via ffmpeg-devel wrote:
> If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic` to LDFLAGS.

I've already been using it since I switched to Xcode 15.

Cheers,
   K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[James Almer]

On 3/16/2024 11:26 AM, Christopher Degawa wrote:
> On Sat, Mar 16, 2024 at 09:08 Gnattu OC via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
>> If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic`
>> to LDFLAGS.  During configure you will also need to set
>> `--host-ldflags='-Wl,-ld_classic’`.
>>
>>> On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek <tessarek@evermeet.cx>
>> wrote:
>>>
>>> Hello,
>>>
>>> It's me again - the dude who compiles ffmpeg for macOS... ;-)
>>>
>>> I haven't updated the referenced libbluray, but only compiled ffmpeg the
>> way I always do. The last time was about 3 days ago and all was good.
>>>
>>> This is the git hash of ffmpeg I tried to compile: b47abd5737
>>>
>>> duplicate symbol '_dec_init' in:
>>>     fftools/ffmpeg_dec.o
>>>     /Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o)
>>> ld: 1 duplicate symbol for architecture x86_64
>>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>>
>>> The only code that changed was ffmpeg and libx265, thus I suspect it was
>> a change to ffmpeg. I can't really do a git bisect, because this error only
>> happens after ffmpeg is compiled at the linker stage, so that would take me
>> forever....
>>>
>>> However, the dev who did a change related to this would probably know
>> right away.
>>>
>>> Cheers,
>>>   K. C.
>>>
>>>
>>> --
>>> regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
>>> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
>>>
>>> /*
>>>    Thou shalt not follow the NULL pointer for chaos and madness
>>>    await thee at its end.
>>> */
>>> _______________________________________________
>>> 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".
>>
>> _______________________________________________
>> 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".
> 
> 
> 
> 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.
_______________________________________________
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".

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

[Helmut K. C. Tessarek]

[-- Attachment #1.1.1: Type: text/plain, Size: 1575 bytes --]

Hi,

On 2024-03-16 10:26, Christopher Degawa wrote:
> 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.

Hmm, this commit in ffmpeg broke the possibility to link ffmpeg with 
libbluray. Just to make this perfectly clear, before that commit it 
worked without issues.

This means that nobody is able to use libbluray and ffmpeg from this 
point forward. I am sorry, but this commit should be reverted.

The commit message reads: Rename dec_open to dec_init(), as it is more 
descriptive of its new purpose.

Who cares about how descriptive it is as long as it works. Now it 
doesn't. This was not a change to implement a feature or fix a bug, but 
a simple refactor, because somebody didn't like the name.

In reality I agree with you that it might be better for libbluray to use 
a prefix/namespace or whatever.  But until then, ffmpeg should still be 
able to be linked with libbluray.

Is my standpoint unreasonable? If so, why?

Cheers,
   K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Gnattu OC via ffmpeg-devel]

Can you try to change the `BD_PRIVATE` to `__attribute__((visibility("hidden")))` in the line defines `dec_init` src/libbluray/disc/dec.h then recompile libbluray to see if it fixes the linking issue?

> On Mar 17, 2024, at 05:09, Helmut K. C. Tessarek <tessarek@evermeet.cx> wrote:
> 
> Hi,
> 
> On 2024-03-16 10:26, Christopher Degawa wrote:
>> 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.
> 
> Hmm, this commit in ffmpeg broke the possibility to link ffmpeg with libbluray. Just to make this perfectly clear, before that commit it worked without issues.
> 
> This means that nobody is able to use libbluray and ffmpeg from this point forward. I am sorry, but this commit should be reverted.
> 
> The commit message reads: Rename dec_open to dec_init(), as it is more descriptive of its new purpose.
> 
> Who cares about how descriptive it is as long as it works. Now it doesn't. This was not a change to implement a feature or fix a bug, but a simple refactor, because somebody didn't like the name.
> 
> In reality I agree with you that it might be better for libbluray to use a prefix/namespace or whatever.  But until then, ffmpeg should still be able to be linked with libbluray.
> 
> Is my standpoint unreasonable? If so, why?
> 
> Cheers,
>  K. C.
> 
> -- 
> regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> _______________________________________________
> 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".

_______________________________________________
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".

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

[Timo Rothenpieler]

On 17.03.2024 09:05, Gnattu OC via ffmpeg-devel wrote:
> Can you try to change the `BD_PRIVATE` to `__attribute__((visibility("hidden")))` in the line defines `dec_init` src/libbluray/disc/dec.h then recompile libbluray to see if it fixes the linking issue?

It only breaks when statically linking. The symbol is not exported by libbr.
Just rename it with a define in CPPFLAGS and call it a day until they 
fix it in libbr.

_______________________________________________
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".

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

[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.


>_______________________________________________
>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".
_______________________________________________
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".

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

[Andreas Rheinhardt]

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.

- Andreas

_______________________________________________
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".

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

[Rémi Denis-Courmont]

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.

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-request@ffmpeg.org with subject "unsubscribe".

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

[Helmut K. C. Tessarek]

[-- Attachment #1.1.1: Type: text/plain, Size: 717 bytes --]

On 2024-03-17 08:10, Timo Rothenpieler wrote
> It only breaks when statically linking. The symbol is not exported by 
> libbr.

In this case the only fix is to use a prefix in libbr, and who knows 
whether they will do that. I opened an issue with them but haven't 
received a reply yet.

> Just rename it with a define in CPPFLAGS and call it a day until they 
> fix it in libbr.

What is "it" and where? in the ffmpeg code or libbr?

Cheers,
   K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
    Thou shalt not follow the NULL pointer for chaos and madness
    await thee at its end.
*/

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Timo Rothenpieler]

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.

> 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-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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".

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

[Helmut K. C. Tessarek]

[-- Attachment #1.1.1: Type: text/plain, Size: 391 bytes --]

I fixed it on my dev machine by renaming the function in libbluray and 
creating a new lib.

I still think that this is a temporary hack and should be fixed 
properly. I've opened an issue with libbluray, so I hope that I'll get a 
reply at one point.

I'm still not entirely sure who actually has to fix this. But I guess it 
will be determined in due time.

Cheers,
   K. C.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Rémi Denis-Courmont]

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).

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-request@ffmpeg.org with subject "unsubscribe".

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

[Timo Rothenpieler]

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".

Re: [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@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@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.

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@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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".

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

[Martin Storsjö]

On Sun, 17 Mar 2024, Rémi Denis-Courmont wrote:

> Obviously not. Imported libraries are only there to resolve missing 
> symbols.

Sure - but if resolving the missing symbols brings in those conflicting 
object files, there's not much to do about it. If the static library 
contains dec_init in a standalone object file that nothing references, 
then sure, it won't be an issue. But if linking libbr brings in the object 
file that defines that symbol, we can't get around it.

Example:

$ cat mylib.h
void mylib_func(void);
$ cat mylib.c
#include "mylib.h"
void mylib_func(void) { }
void dec_init(void) { }
$ cat main.c
#include "mylib.h"

void dec_init(void) { }

int main(int argc, char **argv) {
     mylib_func();
     return 0;
}
$ gcc -c mylib.c
$ ar rcs libmylib.a mylib.o
$ gcc -c main.c
$ gcc main.o -o main -L. -lmylib
/usr/bin/ld: ./libmylib.a(mylib.o): in function `dec_init':
mylib.c:(.text+0xb): multiple definition of `dec_init'; 
main.o:main.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

I don't see what you propose that the FFmpeg build system should do 
differently to get around this issue, other than libbr not exposing global 
symbols outside of their namespace.

// Martin
_______________________________________________
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".

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

[Andreas Rheinhardt]

Martin Storsjö:
> On Sun, 17 Mar 2024, Rémi Denis-Courmont wrote:
> 
>> Obviously not. Imported libraries are only there to resolve missing
>> symbols.
> 
> Sure - but if resolving the missing symbols brings in those conflicting
> object files, there's not much to do about it. If the static library
> contains dec_init in a standalone object file that nothing references,
> then sure, it won't be an issue. But if linking libbr brings in the
> object file that defines that symbol, we can't get around it.
> 
> Example:
> 
> $ cat mylib.h
> void mylib_func(void);
> $ cat mylib.c
> #include "mylib.h"
> void mylib_func(void) { }
> void dec_init(void) { }
> $ cat main.c
> #include "mylib.h"
> 
> void dec_init(void) { }
> 
> int main(int argc, char **argv) {
>     mylib_func();
>     return 0;
> }
> $ gcc -c mylib.c
> $ ar rcs libmylib.a mylib.o
> $ gcc -c main.c
> $ gcc main.o -o main -L. -lmylib
> /usr/bin/ld: ./libmylib.a(mylib.o): in function `dec_init':
> mylib.c:(.text+0xb): multiple definition of `dec_init';
> main.o:main.c:(.text+0x0): first defined here
> collect2: error: ld returned 1 exit status
> 
> I don't see what you propose that the FFmpeg build system should do
> differently to get around this issue, other than libbr not exposing
> global symbols outside of their namespace.
> 

I think he wants us to use partial linking for the fftools: Link all the
object files for a given fftool into a single object file and make this
object file export nothing (except main).

- Andreas

_______________________________________________
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".