Hallo Konrad,
vielen Dank für die Erklärungen. LD_DEBUG könnte ich mir mal angucken.
Das Problem besteht darin, dass Du bei VST keine Kontrolle über die Plugin-Bibliotheken hast. Da geht es darum, dass Leute ihre proprietären Plugins verkaufen, die in eine nicht näher zu benennende Software von Steinberg eingeklinkt werden sollen. Die Schnittstelle wird vom SDK bereitgestellt und darübr hinaus darf man keine Annahmen was sonst noch verfügbar sein sollte (d.h. keine GUI usw). Das geht auch mit Windows-DLLs ganz gut, unter *nix muss man wohl die libdl komplett ersetzten.
Inzwischen ist man soweit, dass man auch GPL3-Plugins und GPL3-Hosts zulässt.
Was JUCE angeht: Das ist ein Plattformübergreifendes GUI-Toolkit mit komfortabler Audio- und MIDI-Integration und Schnittstellen zu den üblichen Audio- und MIDI-Plugin-Systemen. Ein wichtiges Merkmal ist, dass es normalerweise statisch gelinkt wird. Es gibt keine gepflegte ABI. Es hat noch weitere Nachteile: Sprachunterstützung und Screenreader sind relativ neu.
Ich mags nicht, aber ich komme nicht drum herum.
Und: Es gibt für mich keine Entscheidungsfreiheit bezüglich Plugins und JUCE-Versionen. Wenn die JUCE-Version nicht stimmt, ist die ABI im Eimer und ich muss es einfach hinnehmen.
Wie kriege ich raus, ob es am Plugin-Verbindungscode oder an der Anwendung oder an inkompatible Bibliotheken liegt?
Viele Grüße Tobias.
Am 12.02.22 um 18:51 schrieb Konrad Rosenbaum:
Hi,
vorweg: ich habe keine Ahnung was JUCE ist und welche Link-Anforderungen es hat.
Fast immer sollte man so eine Situation vermeiden. Du hast keinerlei Garantie dass es funktioniert.
Der Runtime-Linker macht ein paar Annahmen zu dem Zeug das er in den Speicher lädt:
- Jede Bibliothek kommt nur einmal vor, der selbe Name kann auf die selbe Datei abgebildet werden
- Niemand kommt auf die tollkühne Idee absichtlich zwei Versionen der selben Bibliothek zu linken
- Unterschiedliche Module, die gelinkt werden, haben auch unterschiedliche Symbole - wenn ich ein Symbol gefunden habe, brauche ich nicht weiter zu suchen.
- Weak-Symbole zeigen auf identische Funktionalität und es ist egal welche Instanz ich wohin verlinke.
Es gibt noch ein paar mehr Annahmen, aber in jedem Fall ist eine Verletzung der Annahmen keine gute Idee und führt zu viel Ärger und Kopfschmerz.
On 12/02/2022 18:14, Tobias Schlemmer wrote:
Ein VST-Plugin-Host wurde mit JUCE version A gebaut. Ein VST-Plugin wurde mid JUCE version B gebaut.
Der VST-Plugin-Host verwendet ein shared object mit JUCE-Symbolen. Das VST-Plugin ist ein shared object mit JUCE-Symbolen.
Wie kann ich herausfinden, ob der Host ausschließlich gegen seine eigenen JUCE-Symbole gelinkt wird und ob das Plugin ausschließlich gegen seine version gelinkt wird.
Host: Du müsstest den Host zwingen seine Symbole gleich beim Laden aufzulösen und nach Möglichkeit die Symbole im Plugin verstecken (visibility=hidden).
Plugin: du hast keine Garantie. Selbst wenn Du statisch linkst, mit private linkage und visibility=hidden. Selbst interne Symbole werden erst zur Laufzeit aufgelöst, weil der Linker vorher nicht weiß an welcher Adresse eine Funktion landen wird. Symbole im Host zu verstecken ist vermutlich keine gute Idee, wenn andere Plugins noch funktionieren sollen. Selbst wenn das gehen sollte ist es keine Garantie dass die versteckten Symbole wirklich auch nur lokal verlinkt werden.
Wenn das VST-SDK das unterstützt könnte ich gcc anweisen, das Plugin mit visibility=hidden zu compilieren.
Beim Host ist mir das nicht so klar.
Außerdem möchte ich gern anhand der shared objects sehen, welche Symbole exportiert werden. Das geht doch irgendwie mit objdump oder nm. Hat das schonmal jemand gemacht? Wie geht das genau?
ldd zeigt Dir welche Bibliotheken gefunden werden und wo sie hingelegt werden.
nm zeigt Dir welche Symbole exportiert und importiert werden, aber nicht wo sie hergeholt werden.
objdump kann Dir relativ low-level alles anzeigen was an Export, Import, Symboltabellen, Relocations etc. in einer Datei drin ist. Aber Du musst selbst wissen was der Runtime-Linker damit anstellt.
Setze die Variable LD_DEBUG=all und starte Dein Programm - auf stderr bekommst Du eine Liste aller Symbolauflösungen so wie sie live passieren.
Du wirst sehen dass Du eine Menge Möglichkeiten hast, aber bis Du diese Möglichkeiten gelernt hast und rausgefunden hast wie Du den Linker dazu bewegst Symbole umzubiegen, zu verstecken, hart zu binden, etc.pp. bist Du wahrscheinlich wesentlich schneller und effektiver fertig wenn Du einfach alles auf eine einheitliche Version von JUCE portierst und identisch linkst.
Je nachdem was JUCE macht kann es auch unmöglich sein es stabil zu machen: Qt zum Beispiel dreht komplett frei wenn man zwei Versionen der Core-Bibliothek in den Speicher lädt.
Konrad