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

James Almer jamrial at gmail.com
Thu Aug 24 17:31:14 EEST 2017

On 8/24/2017 5:52 AM, wm4 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.

This is not true. I even mentioned how the current set of major versions
had to deal with a bunch of accidental breakages between releases
(mostly in avcodec and avfilter back in the 3.0 and 3.1 days), all
related to ABI.
We had to compromise and release a point version to put fields back in
their original offset.

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

Michael and Hendrik already explained why this is not a good example.

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

Not sure why you call it a fight, but that's the point. The merges are
currently on hold, and I don't know when they will resume (Clément was
waiting for someone to answer about some dash merges, i think), so just
like how we're cherry picking certain commits in the queue I'd very much
like to do the same with the bump related commits.

We're already in the three digit minor version with some libraries,
there are four releases using this set of major version, and a lot of
ABI crap that needs to be cleaned asap. All the "public until this
point, private from this point until this one where things are public
again" crap in some headers, old avpriv_ symbols using GetBitContext
like the one i fixed in 7c9d2ad45f, oversized tables, the ABI part of
the side data split stuff, etc.
Not to mention the deprecated APIs like the old resampler in avcodec.

More information about the ffmpeg-devel mailing list