mpv Update ohne passende Library

03/11/2016 - 22:31 von Andreas Kohlbach | Report spam
Auch wenn ich Debian Testing nutze, sollte es IMO nicht passieren, dass
ein Paket geupdatet wird, eine essentielle Library aber nicht.

Als ich eben den Konsolen-Media-Player mpv (Fork von mplayer) starten
will, kommt:

| mpv was compiled against a different version of FFmpeg/Libav than the
| shared library it is linked against. This is most likely a broken build
| and could result in misbehavior and crashes.
|
| mpv does not support this configuration and will not run - rebuild mpv
| instead.

Und dann bin ich wieder am Shell-Prompt, ohne dass es spielen würde. Gut
dass man mehrere Player hat.

Ich vermute, das Update der ffmpeg Lib wird bald kommen. Trotzdem sollte
so etwas IMO nicht passieren.
Andreas
You know you are a redneck if
you've ever hitchhiked naked,
 

Lesen sie die antworten

#1 Sven Hartge
03/11/2016 - 22:51 | Warnen spam
Andreas Kohlbach wrote:

Auch wenn ich Debian Testing nutze, sollte es IMO nicht passieren,
dass ein Paket geupdatet wird, eine essentielle Library aber nicht.

Als ich eben den Konsolen-Media-Player mpv (Fork von mplayer) starten
will, kommt:

| mpv was compiled against a different version of FFmpeg/Libav than the
| shared library it is linked against. This is most likely a broken build
| and could result in misbehavior and crashes.
|
| mpv does not support this configuration and will not run - rebuild mpv
| instead.

Und dann bin ich wieder am Shell-Prompt, ohne dass es spielen würde.
Gut dass man mehrere Player hat.

Ich vermute, das Update der ffmpeg Lib wird bald kommen. Trotzdem
sollte so etwas IMO nicht passieren.



Das Problem hier ist keines, welches die Distribution zu verantworten
hat.

Der Code von mpv hat einen Check, der prüft, ob die derzeit vorhandene
Bibliothek die gleiche Version hat, wie die, die bei der Kompilation
vorhanden ist.

Dies sollte aber egal sein, solange sich die ABI derLib nicht àndert und
damit eine Änderung der SO-Namens nötig wàre, ist eine Bibliothek
kompatibel. Macht eine Bibliothek trotz gleichem SO-Namens Probleme, so
ist die Bibliothek als defekt anzusehen, weil sie API/ABI-Änderungen
nicht korrekt signalisiert.

In der Vergangenheit wurden solche Code-Teile von den Maintainern
herausgepatcht, weil die Situation, wie sie nun vorliegt, für eine
Binàr-Distribution nichts ungewöhnliches ist.

Das Gleiche würde ja auch passieren, wenn z.B. libav wg. eines
Sicherheitspatches neu hochgeladen wird. Auch hier würde mpv vollkommen
ungerechtfertigt den Dienst einstellen.

Ein simpler Patch könnte so aussehen:

mpv-0.21.0.orig/player/main.c
+++ mpv-0.21.0/player/main.c
@@ -429,6 +429,8 @@ int mp_initialize(struct MPContext *mpct

handle_deprecated_options(mpctx);

+
+/*
if (!print_libav_versions(mp_null_log, 0)) {
// Using mismatched libraries can be legitimate, but even then it's
// a bad idea. We don't acknowledge its usefulness and stability.
@@ -440,6 +442,8 @@ int mp_initialize(struct MPContext *mpct
"configuration and will not run - rebuild mpv instead.");
return -1;
}
+*/
+

if (!mpctx->playlist->first && !opts->player_idle_mode)
return -3;


Sigmentation fault. Core dumped.

Ähnliche fragen