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.
>
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
Le 17 mars 2024 18:21:23 GMT-07:00, Timo Rothenpieler 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 >> 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 a écrit : > Rémi Denis-Courmont: >> >> >> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
On 18.03.2024 01:32, Rémi Denis-Courmont wrote: Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler 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 a écrit : Rémi Denis-Courmont: Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler 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 >> a écrit : >>> Rémi Denis-Courmont: Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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. OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
On 17.03.2024 18:37, Rémi Denis-Courmont wrote: Le 17 mars 2024 10:29:39 GMT-07:00, Andreas Rheinhardt a écrit : Rémi Denis-Courmont: Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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. */ OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
Le 17 mars 2024 10:29:39 GMT-07:00, Andreas Rheinhardt a écrit : >Rémi Denis-Courmont: >> >> >> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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".
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 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
Le 16 mars 2024 13:58:23 GMT-07:00, James Almer 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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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 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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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. */ OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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 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-requ...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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. */ OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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 > 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-requ...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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 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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
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. */ OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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".
