[FFmpeg-devel] Upgrade Trouble

Reinhard Tartler siretart
Tue Dec 1 21:42:53 CET 2009


(it would be nice if you could retain the CC: in your reply)

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Mon, 2009-11-30 at 23:01 +0100, Reinhard Tartler wrote:
>> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> 
>> >> Wouldn't it be much more practical to declare that the version bump
>> >> broke (indirectly) the binary compatibility of the intermediate
>> >> libraries (libavformat, libavcodec, etc.), and thus, bump SONAME on *all*
>> >> libraries that link against libavutil? I think that would be all
>> >> libraries but libswscale.
>> >> 
>> >> This would allow FFmpeg 0.5 and current trunk to be installed in
>> >> parallel and thus, make my life as packager a *lot* easier in this case.
>> >
>> > This would fix things for programs that only have *direct* use of FFmpeg
>> > libraries. However there could still be problems if a program uses other
>> > libraries that internally depend on FFmpeg ones; those indirect
>> > dependencies can still load any older library version into the process.
>> 
>> ah, you mean applications that link both to an intermediate library and
>> e.g. libavcodec? Do you have any examples of those in mind?
>
> A quick search shows mediatomb-common depending on libavformat and
> libffmpegthumbnailer3, and the latter also depends on libavformat.

Okay, you're right. So let me reconsider your idea with versioned
symbols.  Based on your comments, I've done some further experiments on
this.  Using the testscript I posted at the beginning of this thread as
basis, I've now done the following steps:


+ svn co svn://svn.ffmpeg.org/ffmpeg/branches/0.5 src && cd src
[...]
+ ./configure --enable-shared --disable-static --prefix=/var/tmp/ffmpeg/ \
  --enable-swscale --enable-ffmpeg \
  --extra-ldflags=-Wl,--version-script,/var/tmp/ffmpeg/ld-0.5.x

Using this version script ld-0.5.x:

FFMPEG_0.5 {
  global: *;
};

+ make
[...]
+ make install
[...]
+ ldd /var/tmp/ffmpeg/bin/ffmpeg
	linux-vdso.so.1 =>  (0x00007fff42dd4000)
	libswscale.so.0 => /var/tmp/ffmpeg/lib/libswscale.so.0 (0x00007fe1438ad000)
	libavdevice.so.52 => /var/tmp/ffmpeg/lib/libavdevice.so.52 (0x00007fe1436a8000)
	libavformat.so.52 => /var/tmp/ffmpeg/lib/libavformat.so.52 (0x00007fe1433b2000)
	libavcodec.so.52 => /var/tmp/ffmpeg/lib/libavcodec.so.52 (0x00007fe142a0b000)
	libavutil.so.49 => /var/tmp/ffmpeg/lib/libavutil.so.49 (0x00007fe1427fc000)
	libm.so.6 => /lib/libm.so.6 (0x00007fe142579000)
	libc.so.6 => /lib/libc.so.6 (0x00007fe142226000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fe14200f000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007fe141e0b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe143aca000)
+ objdump -T /var/tmp/ffmpeg/bin/ffmpeg

/var/tmp/ffmpeg/bin/ffmpeg:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      DF *UND*	000000000000001b  FFMPEG_0.5  av_iformat_next
0000000000000000      DF *UND*	000000000000058d  FFMPEG_0.5  avpicture_deinterlace
0000000000000000      DF *UND*	0000000000000220  GLIBC_2.2.5 tcsetattr
0000000000000000      DF *UND*	0000000000000006  FFMPEG_0.5  avdevice_version
[...]

Okay, so this version script works as intenden, all symbols are now
marked with the tag FFMPEG_0.5. Now let's continue with ffmpeg trunk
(again, without ffmpeg so that we can use that as test application):

+ svn co svn://svn.ffmpeg.org/ffmpeg/trunk src && cd src
+ ./configure --enable-shared --disable-static --prefix=/var/tmp/ffmpeg/ \
  --disable-ffmpeg \
  --extra-ldflags=-Wl,--version-script,/var/tmp/ffmpeg/ld-trunk.x 

This time with this version script:

FFMPEG_trunk_1 {
  global: *;
};

the version number doesn't matter right now, however it must exist and
be different to FFMPEG_0.5. With this I compile and upgrade ffmpeg
again:

+ make
[...]
+ make install
[...]
+ ldd /var/tmp/ffmpeg/bin/ffmpeg
/var/tmp/ffmpeg/bin/ffmpeg: /var/tmp/ffmpeg/lib/libswscale.so.0: version `FFMPEG_0.5' not found (required by /var/tmp/ffmpeg/bin/ffmpeg)
/var/tmp/ffmpeg/bin/ffmpeg: /var/tmp/ffmpeg/lib/libavdevice.so.52: version `FFMPEG_0.5' not found (required by /var/tmp/ffmpeg/bin/ffmpeg)
/var/tmp/ffmpeg/bin/ffmpeg: /var/tmp/ffmpeg/lib/libavcodec.so.52: version `FFMPEG_0.5' not found (required by /var/tmp/ffmpeg/bin/ffmpeg)
/var/tmp/ffmpeg/bin/ffmpeg: /var/tmp/ffmpeg/lib/libavformat.so.52: version `FFMPEG_0.5' not found (required by /var/tmp/ffmpeg/bin/ffmpeg)
	linux-vdso.so.1 =>  (0x00007fff75894000)
	libswscale.so.0 => /var/tmp/ffmpeg/lib/libswscale.so.0 (0x00007f2f9808b000)
	libavdevice.so.52 => /var/tmp/ffmpeg/lib/libavdevice.so.52 (0x00007f2f97e85000)
	libavformat.so.52 => /var/tmp/ffmpeg/lib/libavformat.so.52 (0x00007f2f97bcb000)
	libavcodec.so.52 => /var/tmp/ffmpeg/lib/libavcodec.so.52 (0x00007f2f970a0000)
	libavutil.so.49 => /var/tmp/ffmpeg/lib/libavutil.so.49 (0x00007f2f96e91000)
	libm.so.6 => /lib/libm.so.6 (0x00007f2f96c0e000)
	libc.so.6 => /lib/libc.so.6 (0x00007f2f968bb000)
	libavutil.so.50 => /var/tmp/ffmpeg/lib/libavutil.so.50 (0x00007f2f966aa000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f2f96493000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2f982ac000)
+ objdump -T /var/tmp/ffmpeg/bin/ffmpeg

/var/tmp/ffmpeg/bin/ffmpeg:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000000      DF *UND*	000000000000001b  FFMPEG_0.5  av_iformat_next
0000000000000000      DF *UND*	000000000000058d  FFMPEG_0.5  avpicture_deinterlace
0000000000000000      DF *UND*	0000000000000220  GLIBC_2.2.5 tcsetattr
[...]

[full buildlog available on request]

so yes, the application ('FFmpeg' in this case) tries to resolve the
symbols that have been versioned as FFMPEG_0.5 at compilation time. It
fails to resolve them, because the libraries that didn't change SONAME
have been replaced with current FFmpeg trunk.

Did I misunderstand symbol versioning (again)? Are my versioning scripts
wrong?

>> I guess that we can fix all of them with simple rebuilds, which can be
>> done very easily for both distros I work on.
>
> Rebuilding just the applications is not necessarily enough. In the above
> case things would work as long as _neither_ mediatomb-common nor
> libffmpegthumbnailer3 uses new libavformat; but they'd need to be
> rebuilt at the same time. I'm not sure how much more practical this
> would become than "upgrade everything to the new libraries at once",
> which you're obviously not considering to be a practical solution.

I'd very much favor if I can avoid this.

So recompiling the world to pickup the versioned symbols of FFMPEG_0.5
seems unavoidable, but a 'safe' thing to do.  Still, if I upgrade FFmpeg
to current trunk, the old binaries still need to access the
implementations of the symbols of FFmpeg 0.5. With these considerations
I come to the conclusion that both is needed: In order to allow FFmpeg
0.5 to be co-installable with current trunk a SONAME bump on everything
built against libavutil50 *in addition* to symbol versioning.

Correct?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




More information about the ffmpeg-devel mailing list