On 7/5/2020 12:46 PM, Jan Engelhardt wrote:
>
> On Sunday 2020-07-05 16:43, Timo Rothenpieler wrote:
>>> LIBAVCODEC_58 {
>>> global:
>>> av_foo;
>>> av_bar;
>>> av_whatever_else_there_is;...
>>> local:
>>> *;
>>> };
>>> LIBAVCODEC_58.91 {
>>> global:
>>> avpriv_mpeg4audio_get_config2;
>>> } LIBAVCODEC_58;
>>> LIBAVCODEC_58.123 { /* future example */
>>> global:
>>> avblahblah;
>>> } LIBAVCODEC_58.91;
>>
>> Won't that break the entire ABI of anything currently linked, and thus would
>> require a major bump?
>
> Since 4.3 was sort of a break over 4.2.3 already
No, it wasn't. No field offsets were changed, no public structs where
their size is part of the ABI were altered, and no public symbols were
removed. The situation is exactly the same as when 4.2 was released
after 4.1, and every other release before those.
If you can run 4.3 at runtime on a program that linked to 4.2, then it's
working as intended. Attempting the inverse is not and will never be
allowed or considered a valid scenario.
And i want to stress the fact that the reported Chromium breakage and
most assuredly also the Blender breakage are unrelated to what you're
arguing about in this thread.
> , the situation is that:
>
> * $nextrelease can be compatible with 4.2.3's idea of the ABI, in which case
> avpriv_mpeg4audio_get_config2 should be placed inside LIBAVCODEC_58.91, or
>
> * $nextrelease can be compatible with 4.3's idea of the ABI, in which case
> avpriv_mpeg4audio_get_config2 should be placed inside LIBAVCODEC_58.
>
> Each of the two prior options is equally non-compelling. "58" is tarnished
> already.
As "tarnished" as every previous soname was, if we go by your definition
of breakage. I don't recall it ever being an issue for anyone until now.
This nonetheless is a good proposal and can be considered for the next
soname bump, if it can help prevent people using the wrong release at
runtime.
> What software generally does at this point — ffmpeg is not the first
> project to have these issues — is to bump and start fresh.
>
>
>> Generally, this seems incredibly hard to maintain and will very likely cause
>> confusion every time someone adds stuff in the future.
>
> How often do exported functions get added? Between 4.2.3 and 4.3,
> that was _just one_, and that one was even an avpriv_* (which
> probably shouldn't have been exported given its "priv" nature?!).
avpriv_* are inter library communication functions. An unfortunate
consequence of having the project split across half a dozen libraries.
They need to be exported, but not exposed in the installed headers.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
