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.

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