Hallo, folgender Anwendungsfall: Ich habe eine Applikation, welche Funktionalitäten mehrerer dynamisch gelinkter Librarys (*.so) verwendet. Bsp.: MyApplication (executable) MySharedObject1 (library) MySharedObject2 (library) Jedes dieser shared objects verwendet wiederum Funktionalitäten einer statischen Library (*.a) und wird gegen diese gelinkt. Allerdings ist die statische Library für jedes dieser shared objects leicht modifiziert, die Schnittstellen (Bezeichner von Funktionen und globalen Variablen) sind allerdings identisch. Bsp.: MyApplication (executable) MySharedObject1 + MyStaticLib1 MySharedObject2 + MyStaticLib2 Problem: Wenn in MySharedObject2 eine Methode der MyStaticLib2 während der Applikationslaufzeit aufgerufen wird und MySharedObject1 zuerst von der Applikation angezogen wurde, so wird die Methode aus der MyStaticLib1 verwendet. Gibt es eine Möglichkeit, dem GCC (Version 3.3) dieses Verhalten (welches natürlich so spezifiziert ist) abzugewöhnen? Gruß, Alex
Die Methode wäre hier, die entsprechenden Daten zu kapseln. Du musst also nahezu alle Funktionen als static deklarieren und sie dann über irgendeine Registrierfunktion oder -objekt (struct) in deinen eigentlichen Code einbinden. Beispiele für solche Dinge sollten sich in verschiedenen Projekten finden. Einfach nur gleichnamige Funktionen zusammenpappen, das geht nicht gut. Alternativ kannst du mal gucken, ob du mit einem expliziten dlopen()/dlclose() (statt über den dynamischen Linker und eine zur Linkzeit bekannte Bibliothek) besser fährst.
Schau mal hier: http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Function-Attributes.html Vielleicht mal mit weak oder visibility experimentieren oder -fvisibility. Aber das läuft wohl auf Experimente hinaus.
weak hilft nur zur Linkzeit selbst. Damit wird entschieden, dass ein (non-weak) Symbol aus der Applikation Vorrang vor einem weak- Symbol der Bibliothek bekommt, statt einen "duplicate defined symbol"-Fehler zu erzeugen.
Hi, visibility = hidden schaut doch eigentlich erfolgsversprechend aus ?! Die statische Lib mit versteckten Symbolen wird halt statisch gegen mein shared object gelinkt (zu diesem Zeitpunkt sollten denn auch alle nötigen Symbole gefunden werden, zumindest die, welche in der statischen Lib sind). Während der Laufzeit versucht der dynamic linker dann logischerweise auch nicht sämtliche Symbole neu aufzulösen und das shared object verwendet die Funktionen der statisch hinzu gelinkten Lib. Korrekt? Danke für eure Ideen, Alex
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.