[FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries

[Hendrik Leppkes]

On Thu, Aug 24, 2017 at 10:52 AM, wm4 <nfxjfg at googlemail.com> wrote:
> On Wed, 23 Aug 2017 19:23:12 -0300
> James Almer <jamrial at gmail.com> wrote:
>
>> On 8/21/2017 2:51 PM, wm4 wrote:
>> > From: Pedro Pombeiro <pedropombeiro at gmail.com>
>> >
>> > DLL data imports cause problems on Windows. They normally require
>> > each variable to be correctly marked with dllimport/dllexport
>> > declspecs. For MSVC, we define av_export to dllimport declspec. This
>> > is not entirely correct - depending on which sub-lib is built, they
>> > should be marked to dllexport instead. It happens to work with MSVC,
>> > because it supports exports incorrectly marked as imports. Trying to
>> > use this breaks on MinGW and results in linker errors.
>> >
>> > On MinGW, not using any import/export specifiers happens to work,
>> > because binutils and the MinGW runtime provide "pseudo relocations",
>> > which manually fix these imports at load time. This does not work with
>> > MinGW WinRT builds: the relocations cannot be performed because this
>> > would require writing to the code section, which is not allowed.
>> >
>> > Get rid of all these issues by not using data exports/imports. The
>> > public API is already free of them, but avpriv_ symbols make extensive
>> > use of them. Replace them all with getters.
>>
>> Should be good i think, but it can't be applied as is until the next
>> major bump as it breaks ABI (Tons of avpriv_ symbols are removed).
>
> Well, I call bullshit. We've never taken ABI compatibility between
> FFmpeg libs seriously, especially not if it was about avpriv functions.
>
> And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is
> authored and committed by you, and changes an avpriv function in an
> incompatible way, without even minor version bumps.
>

That function was added 2 days earlier, clearly still falling into the
grace period of new functions. If you try to find cheap excuses, at
least put some effort into it. :p

avpriv is part of the public ABI and as such cannot be blindly removed.

- Hendrik