Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On 15.02.2019 01:01, Carl Eugen Hoyos wrote: 2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos : please mention ticket #7735. Ping! I remembered the moment i pushed the patch, sorry. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos : > please mention ticket #7735. Ping! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
You changed libavfilter but didn't commit (I guess), please mention ticket #7735. (I didn't test myself, sorry if there is no issue!) I just completely missed the parts in libavfilter. I am thoroughly confused why this did not break compilation for me. Will push the missing part asap. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-15 0:13 GMT+01:00, Hendrik Leppkes : > On Thu, Feb 14, 2019 at 11:36 PM Carl Eugen Hoyos > wrote: >> >>> No, this entire mess with duplicated ff_ symbols is specifically to >> >>> avoid having to include it in the ABI. >> >> >> >> But old libavcodec does not work with new libavutil now or am I wrong? >> > >> > Is that really a thing we expect or advertise to work? It does not seem >> > sane and I'd expect a lot of other things to explode. >> >> We don't "advertise" it but it is certainly expected from any half-sane >> project. > > Its not a problem in any "normal" case. No ff_ symbols are exported, > so dynamic linking would never use it. > What might not work in the future is mixing static libraries of > different versions, but anyone that does something like that is truely > insane anyway. That may be reasonable. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On Thu, Feb 14, 2019 at 11:36 PM Carl Eugen Hoyos wrote: > >>> No, this entire mess with duplicated ff_ symbols is specifically to > >>> avoid having to include it in the ABI. > >> > >> But old libavcodec does not work with new libavutil now or am I wrong? > > > > Is that really a thing we expect or advertise to work? It does not seem > > sane and I'd expect a lot of other things to explode. > > We don't "advertise" it but it is certainly expected from any half-sane > project. Its not a problem in any "normal" case. No ff_ symbols are exported, so dynamic linking would never use it. What might not work in the future is mixing static libraries of different versions, but anyone that does something like that is truely insane anyway. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 23:17 GMT+01:00, Timo Rothenpieler : > On 14.02.2019 19:59, Carl Eugen Hoyos wrote: >> 2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : >>> On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos >>> wrote: > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > ffmpeg | branch: master | Timo Rothenpieler | > Fri Feb 8 22:47:01 2019 +0100| > [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo > Rothenpieler > > avutil/cuda_check: avoid pointlessly exporting same symbol from two > libraries > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > --- > > libavcodec/Makefile | 6 +++--- > libavcodec/cuda_check.c | 1 - > libavutil/Makefile | 2 +- > libavutil/cuda_check.c | 45 > - Apart from breaking compilation doesn’t this also break ABI? > > I got reports about this breaking compilation in its old state, which > caused me to to turn it into a static inline header-only function. > > For my this compiles and works fine, is there any constellation/compiler > where it doesn't? You changed libavfilter but didn't commit (I guess), please mention ticket #7735. (I didn't test myself, sorry if there is no issue!) >>> No, this entire mess with duplicated ff_ symbols is specifically to >>> avoid having to include it in the ABI. >> >> But old libavcodec does not work with new libavutil now or am I wrong? > > Is that really a thing we expect or advertise to work? It does not seem > sane and I'd expect a lot of other things to explode. We don't "advertise" it but it is certainly expected from any half-sane project. >> In any case, shouldn't the function have another name if it is static >> now? > > No idea if there is any naming convention for static inline header-only > functions. I kept it as is to avoid having to touch even more files, but > renaming it is of course no big deal. I thought that "ff_" is not for static functions. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On 14.02.2019 19:59, Carl Eugen Hoyos wrote: 2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : ffmpeg | branch: master | Timo Rothenpieler | Fri Feb 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo Rothenpieler avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 --- libavcodec/Makefile | 6 +++--- libavcodec/cuda_check.c | 1 - libavutil/Makefile | 2 +- libavutil/cuda_check.c | 45 - Apart from breaking compilation doesn’t this also break ABI? I got reports about this breaking compilation in its old state, which caused me to to turn it into a static inline header-only function. For my this compiles and works fine, is there any constellation/compiler where it doesn't? No, this entire mess with duplicated ff_ symbols is specifically to avoid having to include it in the ABI. But old libavcodec does not work with new libavutil now or am I wrong? Is that really a thing we expect or advertise to work? It does not seem sane and I'd expect a lot of other things to explode. In any case, shouldn't the function have another name if it is static now? No idea if there is any naming convention for static inline header-only functions. I kept it as is to avoid having to touch even more files, but renaming it is of course no big deal. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : > On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: >> >> >> >> > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : >> > >> > ffmpeg | branch: master | Timo Rothenpieler | >> > Fri Feb 8 22:47:01 2019 +0100| >> > [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo >> > Rothenpieler >> > >> > avutil/cuda_check: avoid pointlessly exporting same symbol from two >> > libraries >> > >> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 >> > --- >> > >> > libavcodec/Makefile | 6 +++--- >> > libavcodec/cuda_check.c | 1 - >> > libavutil/Makefile | 2 +- >> >> > libavutil/cuda_check.c | 45 >> > - >> >> Apart from breaking compilation doesn’t this also break ABI? >> > > No, this entire mess with duplicated ff_ symbols is specifically to > avoid having to include it in the ABI. But old libavcodec does not work with new libavutil now or am I wrong? In any case, shouldn't the function have another name if it is static now? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: > > > > > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > > > ffmpeg | branch: master | Timo Rothenpieler | Fri > > Feb 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | > > committer: Timo Rothenpieler > > > > avutil/cuda_check: avoid pointlessly exporting same symbol from two > > libraries > > > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > > --- > > > > libavcodec/Makefile | 6 +++--- > > libavcodec/cuda_check.c | 1 - > > libavutil/Makefile | 2 +- > > > libavutil/cuda_check.c | 45 - > > Apart from breaking compilation doesn’t this also break ABI? > No, this entire mess with duplicated ff_ symbols is specifically to avoid having to include it in the ABI. The compilation error should of course be fixed. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
> Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > ffmpeg | branch: master | Timo Rothenpieler | Fri Feb > 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | > committer: Timo Rothenpieler > > avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > --- > > libavcodec/Makefile | 6 +++--- > libavcodec/cuda_check.c | 1 - > libavutil/Makefile | 2 +- > libavutil/cuda_check.c | 45 - Apart from breaking compilation doesn’t this also break ABI? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel