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

[James Almer]

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).

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.