Library-Handling unter "Unix"

[Alex (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Florian (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Alex (Gast)]

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