Nun, um das wirklich zu verstehen, muß man erst einmal wissen, was die Symlinks bewirken ...
Es gibt in der *ix-Welt etwas, das sich "libhell" nennt, frei übersetzt "Die Hölle der Bibliotheken".
Um die wiederum zu verstehen, muß man wissen, was Libraries oder Bibliotheken sind:
Würde ein Programmierer ein Programm komplett alleine realisieren , so daß es auf dem nackten Betriebssystem läuft, bräuchtest Du wegen der Größe für jedes nicht-triviale Programm eine eigene Festplatte und es gäbe sehr viel weniger Programme auf der Welt, weil der Aufwand utopisch wäre.
Also nutzt man Bibliotheken, angefangen von denen, die schon zum Grundgerüst der Programmiersprache gehören und z.B. mathematische Operationen wie Addition, Subtraktion, Division usw. erlauben, ohne daß der Programmierer dafür Bits durch Register schieben muß (Tatsächlich können Computer-Prozessoren nicht einmal alle Grundrechenarten von sich aus, was sie auch nicht müssen, weil sie statt z.B. "3 Mal 7" auch sehr schnell 7+7+7 berechnen können, was bekanntlich zum selben Ergebnis kommt).
Bei Linux wäre das i.d.R. libgcc, bei Windows sehr häufig die diversen Visual C++ Runtimes.
Dazu kommen dann bei komplexeren Programmen noch x weitere Bibliotheken hinzu, je nach Bedarf z.B. für grafische Ausgaben, Kommunikation mit bestimmten Schnittstellen, Kryptographie, etc. pp.
Welche das bei oscam sind, hat ds777 ja schon aufgeführt.
Nun zu der Hölle, die diese Bibliotheken unter Linux darstellen:
Die Entwicklung geht bekanntlich ständig weiter, also gibt es auch immer wieder mal neue Versionen dieser Bibliotheken und diese Versionen sind nicht immer 100%ig zueinander kompatibel.
Das alleine ist noch gar kein Problem, die Bibliotheken kriegen nämlich einfach ihre Versionsnummer mit in den Dateinamen gepackt, so daß man mehrere Versionen gleichzeitig installiert haben kann und jedes Programm nutzt einfach die Version, "gegen" die es gebaut wurde.
In dem Bezug unterscheiden sich Linux und Windows auf den ersten Blick überhaupt nicht, auf jedem Windows-Rechner mit ein paar unterschiedlichen installierten Programmen findet man früher oder später unter "Apps" dieses Bild vor:
Unter Windows funktioniert das allerdings auch wirklich, unter Linux nur theoretisch.
Die Visual C++ 2012 Runtime ist nämlich wirklich kompatibel zu jeder anderen Unterversion (und Unterunterversion) der Visual C++ 2012 Runtime, also funktioniert ein Programm, das 2011 gegen die Urversion der Visual C++ 2012 Runtime gebaut wurde, auch immer noch, wenn eine wegen Sicherheitsupdates im Jahr 2019 aktualisierte Version der Visual C++ 2012 Runtime auf dem System liegt.
Theoretisch soll das unter *ix genauso funktionieren, dazu gibt es entsprechende Links unter /usr/lib und /lib:
Bedeutet: Ein Programm, das gegen libusb-0.1 Unterversion 4 gebaut wurde, wird aufgrund des Symlinks libusb-0.1.so.4 -> libusb-0.1.so.4.4.4 die Unterunterversion 4.4.4 benutzen und ein Programm, welches für libusb-1.0 Unterversion 0 gebaut wurde, dessen Unterunterversion 0.1.0.
Ein Programm, das gegen libusb-0.1.so.3 gebaut wurde, würde auf diesem System schon nicht mehr laufen, dazu müßte man erst einmal eine libusb-0.1 Unterversion 3.x.y besorgen ...
Aber es kommt noch schlimmer:
Unter Linux-Programmierern gilt anscheinend der Ehrenkodex, auch mit jeder neuen Unterunterversion irgendetwas so massiv zu verändern, daß man sein Programm einmal komplett umschreiben muß.
Deshalb funktioniert der theoretisch immer selbe Vorgang zum Bauen eines Programms
in der Praxis auch selten bis nie, sondern endet praktisch immer beim ./configure mit:
libqpdf 8.3.0 und 8.0.2 kann man aber nicht gleichzeitig installiert haben, da ja beide den gleichen Namen "libqpdf.so.8" haben. Das Bauen von libqpdf 8.3.0 scheitert dann wieder an einer anderen zu alten (oder auch zu neuen) Lib und außerdem müßte man dann auch wissen, was noch gegen libqpdf 8.0 .2 gebaut wurde und auch diese Programme neu bauen (Sofern sie gegen die neuere Version noch bauen), usw. usf.
Daher dann der Linux-Marktanteil von 1% auf den Desktop-Rechnern ... auf lange Sicht kommt
jeder in die Libhell ...
Und jetzt kommen wir dazu, was diese manuellen Symlinks auf dem System anrichten:
Nehmen wir einmal an, jemand anderes baut für Dich einen oscam und nutzt dabei eine Toolchain, die OpenSSL 1.0.x beinhaltet, aber Du willst den oscam danach auf einem alten Image einsetzen, bei dem OpenSSL noch auf dem Stand von 0.9.8 ist, dann schiebst Du diesem oscam durch den Symlink
/usr/lib/libssl.so.1.0.2 -> libssl.so.0.9.8
die alte Version 0.9.8 als die Version 1.0.2 unter, die er gerne hätte.
Solange oscam nur solche Funktionen aus libssl 1.0.2 benutzt, die seit 0.9.8
nicht geändert wurden, dann wird das sogar funktionieren. Aber ohne den gesamten Programmcode von oscam genau zu studieren, ob nicht evtl. alle paar Tage bei Karte x doch eine neuere Funktion so wie in 1.0.2 benötigt wird, weiß man nicht, ob der oscam auch dauerhaft stabil läuft.
Was passiert nun, wenn Du in Deiner Toolchain auf die Version von OpenSSL up- oder auch downgradest, die Du
wirklich auch im Image hast?
Nun, dann wird oscam gegen genau diese Version gebaut. Der so gebaute oscam wird nun
1. auch ohne den Symlink /usr/lib/libssl.so.1.0.2 -> libssl.so.0.9.8 auf libssl.so.0.9.8 zugreifen, denn gegen die wurde er ja auch gebaut, der Symlink /usr/lib/libssl.so.1.0.2 kann dann weg.
2. mit höherer Wahrscheinlichkeit stabil laufen, denn ein Programm kann durch entsprechende Statements im Programmcode so geschrieben werden, daß es sauber gegen unterschiedlichen Versionen einer Lib gebaut werden kann.
