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 librarieshttp://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
