Opened 10 years ago
Closed 10 years ago
#3136 closed defect (fixed)
ABI in libavutil as been broken since 2.x without libary soname change
Reported by: | marillat | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avutil |
Version: | git-master | Keywords: | regression |
Cc: | Michael Niedermayer | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Hi,
Would be nice to know when a libavutil major version bump
(liavutil53) is scheduled. For now it is completely impossible
to use ffmpeg 2.0 (and 2.1) without a rebuild for all packages
who depends on libavutil52.
In Debian this means 170 packages.
Here is Michael's comment about this bug :
http://thread.gmane.org/gmane.comp.video.ffmpeg.cvs/66227/focus=66238
Christian
Change History (14)
follow-up: 2 comment:1 by , 10 years ago
Keywords: | regression added |
---|---|
Priority: | normal → important |
Version: | 2.0.2 → git-master |
comment:2 by , 10 years ago
Replying to cehoyos:
How can this be fixed in your opinion?
By changing the library soname to 53 (in ffmpeg 2.x and 2.1) then both libraries
52 and 53 are installable in parallel.
Christian
follow-up: 4 comment:3 by , 10 years ago
Its quite unfortunate that this issue hasnt been raised louder earlier.
But how bad is the issue really ?
I would assume that few applications use the lls code from libavutil.
So naively thinking maybe only very few need to be rebuild.
follow-up: 5 comment:4 by , 10 years ago
Replying to michael:
Its quite unfortunate that this issue hasnt been raised louder earlier.
But how bad is the issue really ?
I would assume that few applications use the lls code from libavutil.
So naively thinking maybe only very few need to be rebuild.
May be not all application uses lls code directly, but at least major application like vlc and XBMC doesn't work.
follow-up: 6 comment:5 by , 10 years ago
Replying to marillat:
Replying to michael:
Its quite unfortunate that this issue hasnt been raised louder earlier.
But how bad is the issue really ?
I would assume that few applications use the lls code from libavutil.
So naively thinking maybe only very few need to be rebuild.
May be not all application uses lls code directly, but at least major application like vlc and XBMC doesn't work.
Ok, then there is a problem, how can i reproduce that ? what was vlc compiled against and what linked against ? (same question for xbmc)
also i dont see any use of lls in vlc
and am i assuming correctly that you build libavutil and libavcodec new ? libavcodec does use the lls code
follow-up: 7 comment:6 by , 10 years ago
Replying to michael:
Replying to marillat:
Replying to michael:
Its quite unfortunate that this issue hasnt been raised louder earlier.
But how bad is the issue really ?
I would assume that few applications use the lls code from libavutil.
So naively thinking maybe only very few need to be rebuild.
May be not all application uses lls code directly, but at least major application like vlc and XBMC doesn't work.
Ok, then there is a problem, how can i reproduce that ? what was vlc compiled against and what linked against ? (same question for xbmc)
also i dont see any use of lls in vlc
and am i assuming correctly that you build libavutil and libavcodec new ? libavcodec does use the lls code
Debian unstable i386 packages from my repository deb-multimedia.org
Installed ffmpeg 1.2.4-dmo3 and then upgraded to 2.1.0-dmo2
vlc 2.1.1-dmo1
[0x8d408f8] main libvlc warning: cannot load module `/usr/lib/vlc/plugins/stream_out/libstream_out_chromaprint_plugin.so' (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference) [0x8d408f8] main libvlc warning: cannot load module `/usr/lib/vlc/plugins/codec/libavcodec_plugin.so' (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference) [0x8d408f8] main libvlc warning: cannot load module `/usr/lib/vlc/plugins/access/libaccess_avio_plugin.so' (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference) [0x8d408f8] main libvlc warning: cannot load module `/usr/lib/vlc/plugins/demux/libavformat_plugin.so' (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference)
xbmc 13.0~alpha9-dmo1
OpenGL Warning: glTestFenceNV not found in mesa table /usr/lib/i386-linux-gnu/xbmc/xbmc.bin: relocation error: /usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol /avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file /libavutil.so.52 with link time reference
melt 0.9.0-dmo9 and also kdenlive as this program use melt.
mlt_repository_init: failed to dlopen /usr/lib/i386-linux-gnu/mlt/libmltavformat.so (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference)
x264 0.140.2377+git1ca7bb9-dmo2
x264: relocation error: /usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference
Christian
comment:7 by , 10 years ago
Replying to marillat:
Replying to michael:
Replying to marillat:
Replying to michael:
Its quite unfortunate that this issue hasnt been raised louder earlier.
But how bad is the issue really ?
I would assume that few applications use the lls code from libavutil.
So naively thinking maybe only very few need to be rebuild.
May be not all application uses lls code directly, but at least major application like vlc and XBMC doesn't work.
Ok, then there is a problem, how can i reproduce that ? what was vlc compiled against and what linked against ? (same question for xbmc)
also i dont see any use of lls in vlc
and am i assuming correctly that you build libavutil and libavcodec new ? libavcodec does use the lls code
Debian unstable i386 packages from my repository deb-multimedia.org
Installed ffmpeg 1.2.4-dmo3 and then upgraded to 2.1.0-dmo2
And here are the error messages :
xbmc and x264 doesn't start at all.
vlc:
[0x99fbb80] main decoder error: no suitable decoder module for fourcc `h264'. VLC probably does not support this sound or video format.
melt:
mlt_repository_init: failed to dlopen /usr/lib/i386-linux-gnu/mlt/libmltavformat.so (/usr/lib/i386-linux-gnu/i686/cmov/libavcodec.so.54: symbol avpriv_evaluate_lls, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference) Failed to load "sample.mp4"
Christian
comment:8 by , 10 years ago
Does this patchset (with --enable-old-libavutil52-abi) fix it ?
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/171153
comment:9 by , 10 years ago
Cc: | added |
---|
follow-up: 11 comment:10 by , 10 years ago
An alternative solution, that doesnt need a configure flag posted:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/171166
this basically reintroduces the proper 52 style ABI to libavutil and at the same time makes libavcodec not use the ambigous ABI anymore. So simply upgrading both libs would then resolve it.
Comments and testing very welcome!
About simply bumping major, i think this would cause many more problems than it solves, especially if debian at some future point introduces a incompatible libavutil with that major version from libav.
follow-up: 12 comment:11 by , 10 years ago
Replying to michael:
An alternative solution, that doesnt need a configure flag posted:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/171166
this basically reintroduces the proper 52 style ABI to libavutil and at the same time makes libavcodec not use the ambigous ABI anymore. So simply upgrading both libs would then resolve it.
Comments and testing very welcome!
Works for me.
Should I wait for a new ffmepg 2.1 release ?
About simply bumping major, i think this would cause many more problems than it solves, especially if debian at some future point introduces a incompatible libavutil with that major version from libav.
We already have this sort of issues with libavcodec/libavformat/libavdevice soname is 55 in ffmpeg since 2.0 when lbav still have 54.
follow-up: 13 comment:12 by , 10 years ago
Replying to marillat:
Replying to michael:
An alternative solution, that doesnt need a configure flag posted:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/171166
this basically reintroduces the proper 52 style ABI to libavutil and at the same time makes libavcodec not use the ambigous ABI anymore. So simply upgrading both libs would then resolve it.
Comments and testing very welcome!
Works for me.
ok, thanks
Should I wait for a new ffmepg 2.1 release ?
up to you, ill try to make a new release soon
comment:13 by , 10 years ago
comment:14 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
fixed by b382d09d29be90e0947295a70cdcbaa60b9030b8 and previous commits
commits also backported to 2.1 and 2.0 branches, will be in the next releases
How can this be fixed in your opinion?