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

[wm4]

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.

> Speaking of which, do you or anyone else want to help with applying the
> bump right now instead of waiting until the merges are resumed?
> Finding what deprecated APIs are two years or older, removing them and
> seeing if any further changes are needed to ensure compilation after the
> bump (I bet a lot will require changes since deprecations imported from
> libav aren't given much attention here outside of making sure warnings
> are silenced).
> ABI changes, like moving fields around within a struct or into an opaque
> internal struct, removing/modifying avpriv_ functions, etc, are things
> that can be done during several weeks after the bump and not necessarily
> as preparation for it.
> 
> Certain deprecated APIs that are two years or older could be kept in
> place if removing them takes too much work at the moment, but the bump
> is pretty overdue by now due to the amount of crap some structs are
> currently dealing with (public vs private fields, offsets, etc).
> We've had enough ABI breakages with this set of major versions so it
> would be great if we can move on from it before a new release is tagged.

That sounds good, but I don't think I want to fight this fight (because
it's going to be a fight). Libav already bumped recently.