2019-02-14 23:17 GMT+01:00, Timo Rothenpieler <t...@rothenpieler.org>: > On 14.02.2019 19:59, Carl Eugen Hoyos wrote: >> 2019-02-14 18:21 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>: >>> On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos <ceffm...@gmail.com> >>> wrote: >>>> >>>> >>>> >>>>> Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler <g...@videolan.org>: >>>>> >>>>> ffmpeg | branch: master | Timo Rothenpieler <t...@rothenpieler.org> | >>>>> 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
