[FFmpeg-devel] ABI break in 5.1

[FFmpeg-devel] ABI break in 5.1

[Jan Engelhardt]

This is a follow-up to a topic that was already raised earlier,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html 

The same has now happened to 5.0->5.1.

==========================================
abidiff /usr/lib64/libavcodec.so.59.18.100 b/usr/lib64/libavcodec.so.59.37.100
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 1 Removed, 0 Added function symbol not referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

1 Removed function symbol not referenced by debug info:

  [D] avpriv_h264_has_num_reorder_frames@@LIBAVCODEC_59

==========================================
abidiff /usr/lib64/libavdevice.so.59.4.100 b/usr/lib64/libavdevice.so.59.7.100

==========================================
abidiff /usr/lib64/libavfilter.so.8.24.100 b/usr/lib64/libavfilter.so.8.44.100
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 1 Added function symbol not referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

1 Added function symbol not referenced by debug info:

  [A] av_buffersink_get_ch_layout@@LIBAVFILTER_8

==========================================
abidiff /usr/lib64/libavformat.so.59.16.100 b/usr/lib64/libavformat.so.59.27.100
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 1 Added function symbol not referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

1 Added function symbol not referenced by debug info:

  [A] avio_vprintf@@LIBAVFORMAT_59

==========================================
abidiff /usr/lib64/libavutil.so.57.17.100 b/usr/lib64/libavutil.so.57.28.100
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 47 Added function symbols not referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

47 Added function symbols not referenced by debug info:

  [A] av_channel_description@@LIBAVUTIL_57
  [A] av_channel_description_bprint@@LIBAVUTIL_57
  [A] av_channel_from_string@@LIBAVUTIL_57
  [A] av_channel_layout_channel_from_index@@LIBAVUTIL_57
  [A] av_channel_layout_channel_from_string@@LIBAVUTIL_57
  [A] av_channel_layout_check@@LIBAVUTIL_57
  [A] av_channel_layout_compare@@LIBAVUTIL_57
  [A] av_channel_layout_copy@@LIBAVUTIL_57
  [A] av_channel_layout_default@@LIBAVUTIL_57
  [A] av_channel_layout_describe@@LIBAVUTIL_57
  [A] av_channel_layout_describe_bprint@@LIBAVUTIL_57
  [A] av_channel_layout_from_mask@@LIBAVUTIL_57
  [A] av_channel_layout_from_string@@LIBAVUTIL_57
  [A] av_channel_layout_index_from_channel@@LIBAVUTIL_57
  [A] av_channel_layout_index_from_string@@LIBAVUTIL_57
  [A] av_channel_layout_standard@@LIBAVUTIL_57
  [A] av_channel_layout_subset@@LIBAVUTIL_57
  [A] av_channel_layout_uninit@@LIBAVUTIL_57
  [A] av_channel_name@@LIBAVUTIL_57
  [A] av_channel_name_bprint@@LIBAVUTIL_57
  [A] av_csp_luma_coeffs_from_avcsp@@LIBAVUTIL_57
  [A] av_csp_primaries_desc_from_id@@LIBAVUTIL_57
  [A] av_csp_primaries_id_from_desc@@LIBAVUTIL_57
  [A] av_dynamic_hdr_vivid_alloc@@LIBAVUTIL_57
  [A] av_dynamic_hdr_vivid_create_side_data@@LIBAVUTIL_57
  [A] av_fifo_alloc2@@LIBAVUTIL_57
  [A] av_fifo_auto_grow_limit@@LIBAVUTIL_57
  [A] av_fifo_can_read@@LIBAVUTIL_57
  [A] av_fifo_can_write@@LIBAVUTIL_57
  [A] av_fifo_drain2@@LIBAVUTIL_57
  [A] av_fifo_elem_size@@LIBAVUTIL_57
  [A] av_fifo_freep2@@LIBAVUTIL_57
  [A] av_fifo_grow2@@LIBAVUTIL_57
  [A] av_fifo_peek@@LIBAVUTIL_57
  [A] av_fifo_peek_to_cb@@LIBAVUTIL_57
  [A] av_fifo_read@@LIBAVUTIL_57
  [A] av_fifo_read_to_cb@@LIBAVUTIL_57
  [A] av_fifo_reset2@@LIBAVUTIL_57
  [A] av_fifo_write@@LIBAVUTIL_57
  [A] av_fifo_write_from_cb@@LIBAVUTIL_57
  [A] av_opt_get_chlayout@@LIBAVUTIL_57
  [A] av_opt_set_chlayout@@LIBAVUTIL_57
  [A] av_uuid_parse@@LIBAVUTIL_57
  [A] av_uuid_parse_range@@LIBAVUTIL_57
  [A] av_uuid_unparse@@LIBAVUTIL_57
  [A] av_uuid_urn_parse@@LIBAVUTIL_57
  [A] avpriv_fopen_utf8@@LIBAVUTIL_57

==========================================
abidiff /usr/lib64/libswresample.so.4.3.100 b/usr/lib64/libswresample.so.4.7.100
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 2 Added function symbols not referenced by debug info
Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

2 Added function symbols not referenced by debug info:

  [A] swr_alloc_set_opts2@@LIBSWRESAMPLE_4
  [A] swr_build_matrix2@@LIBSWRESAMPLE_4

==========================================
abidiff /usr/lib64/libswscale.so.6.4.100 b/usr/lib64/libswscale.so.6.7.100

==========================================
abidiff /usr/lib64/libpostproc.so.56.3.100 b/usr/lib64/libpostproc.so.56.6.100

==========================================

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]

Jan Engelhardt (12022-07-23):
> 
> This is a follow-up to a topic that was already raised earlier,
> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html 
> 
> The same has now happened to 5.0->5.1.

I do not see an issue. What issue do you see?

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Jan Engelhardt]

On Saturday 2022-07-23 15:28, Nicolas George wrote:

>Jan Engelhardt (12022-07-23):
>> 
>> This is a follow-up to a topic that was already raised earlier,
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265694.html 
>> 
>> The same has now happened to 5.0->5.1.
>
>I do not see an issue. What issue do you see?

As I have previously explained,
[ http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265705.html ]

>"""A program may have been built with 4.3 but is combined
>with 4.2.3 at runtime, then this can happen:"""

(Or, in today's terms, a program built with 5.1 but which is
combined with 5.0 at runtime, then this can happen:

$ ./a.out 
./a.out: symbol lookup error: ./a.out: undefined symbol: avio_vprintf, 
version LIBAVFORMAT_59

Now, it was clear that

>"""Running against an older version then the build version is never
>supported
>
>A distribution should never allow this to happen."""

This is exactly what we're trying to do. ELF symbol version definitions 
are *the* tool to do this, but we keep getting screwed over by terrible 
symbol version management in ffmpeg.

libavformat.v advertises a verdef (that one being "LIBAVUTIL_59" 
currently), but you keep modifying the set of symbols, such as dropping 
avio_vprintf.

Minus that bug, libavformat.v is but used to do symbol 
visibility. For which you don't need a verdef, for starters.

diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v
index fb17058df5..54dbc84e9a 100644
--- a/libavutil/libavutil.v
+++ b/libavutil/libavutil.v
@@ -1,4 +1,4 @@
-LIBAVUTIL_MAJOR {
+{
     global:
         av*;
     local:

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 2140 bytes --]

Jan Engelhardt (12022-07-23):
> As I have previously explained,
> [ http://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265705.html ]

Read the replies that have been made to you at the time.

> (Or, in today's terms, a program built with 5.1 but which is
> combined with 5.0 at runtime, then this can happen:
> 
> $ ./a.out 
> ./a.out: symbol lookup error: ./a.out: undefined symbol: avio_vprintf, 
> version LIBAVFORMAT_59

This is a perfectly normal outcome.

> >"""Running against an older version then the build version is never
> >supported
> >
> >A distribution should never allow this to happen."""
> 
> This is exactly what we're trying to do. ELF symbol version definitions 
> are *the* tool to do this, but we keep getting screwed over by terrible 
> symbol version management in ffmpeg.

No, the ELF symbol version system cannot prevent you from replacing a
file with an older version. The tool to prevent that is the package
manager of the distribution, and it obviously depends on the
distribution. With Debian, it looks like that:

Depends: libavcodec59 (>= 7:5.0)

What symbol versioning can achieve at most is turn a dangerous late
incompatibility, such as accessing a field that was added in the new
version, into an immediate harmless crash like the one you quoted above.

> libavformat.v advertises a verdef (that one being "LIBAVUTIL_59" 
> currently), but you keep modifying the set of symbols, such as dropping 
> avio_vprintf.

Please point the commit where we dropped avio_vprintf. It would be a
severe mistake. But to the better of my knowledge we avio_vprintf was
added about a month ago and never dropped, and you are mistaken.

> 
> Minus that bug, libavformat.v is but used to do symbol 
> visibility. For which you don't need a verdef, for starters.

Well, make that your lede instead of a dump of a completely useless
report of so-called incompatibilities reported by a tool that does not
know the specifics.

Even better, submit it as an actual patch explaining why and after
checking it does not break anything else.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Jan Engelhardt]

On Saturday 2022-07-23 16:32, Nicolas George wrote:
>
>No, the ELF symbol version system cannot prevent you from replacing a
>file with an older version.

The information in ELF helps package managers prevent such
replacement. If I even try as much as propose a glibc downgrade to
rpm, this will happen:

# rpm -Uhv glibc-2.31-7.30.x86_64.rpm --oldpackage
error: Failed dependencies:
        libc.so.6(GLIBC_2.32)(64bit) is needed by (installed) coreutils-9.0-7.1.x86_64
        libc.so.6(GLIBC_2.33)(64bit) is needed by (installed) libpmem1-1.11.1-1.5.x86_64
        libc.so.6(GLIBC_2.34)(64bit) is needed by (installed) libvpx7-1.11.0-3.4.x86_64
        libm.so.6(GLIBC_2.35)(64bit) is needed by (installed) perl-base-5.36.0-2.1.x86_64

Of course, you can always mv/rm behind the manager's back or use rpm
--force, but that's not the point!

At the time vpx was built, it engrained the symvers of the functions
it uses into itself, therefore e.g. `readelf -aW
/usr/lib64/libvpx.so.7`:

Version symbols section '.gnu.version' contains 93 entries:
 Addr: 0x0000000000001576  Offset: 0x001576  Link: 4 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.2.5)   3 (GLIBC_2.34)    4 (GLIBC_2.3.2)
  004:   5 (GLIBC_2.2.5)   6 (GLIBC_2.11)    5 (GLIBC_2.2.5)   7 (GLIBC_2.29) 
  008:   8 (GLIBC_2.3.4)   1 (*global*)      5 (GLIBC_2.2.5)   4 (GLIBC_2.3.2)
  00c:   8 (GLIBC_2.3.4)   5 (GLIBC_2.2.5)   3 (GLIBC_2.34)    5 (GLIBC_2.2.5)
  010:   3 (GLIBC_2.34)    9 (GLIBC_2.27)    8 (GLIBC_2.3.4)   5 (GLIBC_2.2.5)
  014:   3 (GLIBC_2.34)    5 (GLIBC_2.2.5)   8 (GLIBC_2.3.4)   1 (*global*)   
  018:   3 (GLIBC_2.34)    7 (GLIBC_2.29)    5 (GLIBC_2.2.5)   1 (*global*)   
  01c:   4 (GLIBC_2.3.2)   5 (GLIBC_2.2.5)   3 (GLIBC_2.34)    5 (GLIBC_2.2.5)
  020:   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   3 (GLIBC_2.34)    5 (GLIBC_2.2.5)
  024:   a (GLIBC_2.4)     8 (GLIBC_2.3.4)   4 (GLIBC_2.3.2)   5 (GLIBC_2.2.5)
  028:   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)
  02c:   5 (GLIBC_2.2.5)   4 (GLIBC_2.3.2)   3 (GLIBC_2.34)    7 (GLIBC_2.29) 
  030:   2 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   b (GLIBC_2.14) 
  034:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)   

Managers can and do evaluate that and turn that into a dependency
*without any person having to manually add "Requires: glibc >= 2.34"
to the libvpx description*. This of course requires that the project
followed the procedures to create the symvers definitions, which
glibc did.

Seriously, why do I have to explain this all the time.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 268 bytes --]

Jan Engelhardt (12022-07-23):
> The information in ELF helps package managers prevent such
> replacement.

Key word: help.

> Seriously, why do I have to explain this all the time.

Maybe because you are never convincing.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ABI break in 5.1

[Jean-Baptiste Kempf]

On Sat, 23 Jul 2022, at 16:03, Jan Engelhardt wrote:
> (Or, in today's terms, a program built with 5.1 but which is
> combined with 5.0 at runtime, then this can happen:

FFmpeg 5.1 and 5.0 are two major versions and never ever are guaranteed to be compatible backwardly.

Your tools show that we only added symbols, therefore a program built with 5.0 will run with 5.1 at runtime, which is what .so numbering is about.

We’re not glibc and will never be, because we’re not a libc, nor an OS SDK.

If you build against 5.1, use 5.1 at runtime.

But if you built with 5.0, then 5.1 will run, as expected.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".