Danke fuer die schnelle Antwort:
> Die Adressen von Objekten in einer DLL werden zur Ladezeit jeweils in eine
> Indirektionstabelle (im importierenden Code) geschrieben. Diese Indirektion
> laesst sich bei Prozeduren mit einem 'jump indirect' verstecken, bei
> Variablen ist das aber nicht moeglich.
> Zugriffe auf eine DLL Variable vom Typ T sind
> deshalb nur Moeglich wenn auf der Importseite eine Variable vom Typ 'Pointer
> To T' deklariert und die Dereferenz explizit gemacht wird. Da das sehr
> umstaendlich und verwirrend ist, werden exportiere Variablen in DLLs so gut
> wie nie verwendet (ich habe noch nie eine gesehen). Sie sind in BB deshalb
> auch nicht vorgesehen.
habe ich fast befuerchtet.
Dies beantwortet zumindest den ersten Teil meiner
Frage (die bei meinen Linux Arbeiten aufgetaucht sind).
> > In the "Platform-Specific Issues" there is a description how
> > to interface to C TYPES and PROCEDURES but sorrily no hint
> > how to access variables from a DLL nor how to make a
ich füerchte, dass der zweite Teil damit auch unmöglich ist
> > ... how to make a
> > global CP-variable known to the extern C world.
wäre aber trotzdem für eine definitive Antwort dankbar.
der zugehörige Kontext ist:
Das Problem ist derzeit (ich plane den Port mit dem GTK+ Libraries, die
sowohl unter Win32 als auch Linux existieren), dass ich unter Win32
erfolgreich ein (BB unabhängiges) Fenster öffnen kann, da ein paar
globale Variablen unter Win32 in den DLLs stehen.
Unter Linux scheitert aber das laden des shared objects (DLL) daran,
dass (wahrscheinlich, ich habe noch nicht die Unix *.h durchsucht)
eine globale Variable, die vermutlich das Hauptprogramm deklarieren
soll, von den Libraries nicht gefunden werden.
In den Pascal Bindings für GTK+ habe ich die vom Dynamic Linker als
nicht vorhandenes Symbol angemoserte Variable dann wie folgt (in
einem {$ifdef win32} bedingten Stück) gefunden:
var
gdk_root_window : TWindow;external gdkdll name 'gdk_root_window';
Herzliche Gruesse
Received on Mon Jun 26 2000 - 13:15:47 UTC