Hallo Welt,

sind Bibliotheksdateien (unter Windows z. B. ".lib", ".dll") eigentlich
compilerunabhängig "genormt"? Will sagen, kann eine mit Compiler A
erstellte LIB/DLL (unter dem gleichen OS) generell auch in einem mit
Compiler B erstellten Programm genutzt werden?

(Ich habe dunkel in Erinnerung, dass das nur für Bibliotheken gilt, die
ausschließlich C-Funktionen, nicht aber C++-Elemente wie Klassen
exportieren. Aber dieses Halbwissen ist auch schon lange her, und Tante
Google spuckt auf die Schnelle nichts dazu aus.)

Jens

Jens Lenge schrieb:

> sind Bibliotheksdateien (unter Windows z. B. ".lib", ".dll") eigentlich
> compilerunabhängig "genormt"?

Grob gesagt: nein. Bei den 64-Bit Plattformen gibt es gewisse
Bestrebungen. Es ist natürlich so, dass es immer eine Art System-API
gibt, dass irgendwie ansprechbar sein muss und oft in Form von
Bibliotheken daherkommt. Das ist dann der kleinste gemeinsame Nenner,
den notwendigerweise alle Compiler unterstützen.

> Will sagen, kann eine mit Compiler A
> erstellte LIB/DLL (unter dem gleichen OS) generell auch in einem mit
> Compiler B erstellten Programm genutzt werden?

Nein. Im Allgemeinen funktioniert das nicht einmal mit verschiedenen
Versionen "eines" Compilers.

Die genauen Regeln, Formate und Standards für bestimmte Plattformen sind
dann in den passenden Gruppen zu erfragen.

Jens Lenge wrote:
> sind Bibliotheksdateien (unter Windows z. B. ".lib", ".dll") eigentlich
> compilerunabhängig "genormt"? Will sagen, kann eine mit Compiler A
> erstellte LIB/DLL (unter dem gleichen OS) generell auch in einem mit
> Compiler B erstellten Programm genutzt werden?

Falls es hier eine "Norm" gibt, dann ist sie plattformabhängig.

Unter Windows generieren z.B. Borland und Microsoft ihre .obj-Dateien
und damit auch die .lib-Dateien in unterschiedlichen Formaten. Unter
Linux wirst du mit einer DLL für ein libc5-System in einem libc6-
Programm keine Freude haben.

> (Ich habe dunkel in Erinnerung, dass das nur für Bibliotheken gilt, die
> ausschließlich C-Funktionen, nicht aber C++-Elemente wie Klassen
> exportieren. Aber dieses Halbwissen ist auch schon lange her, und Tante
> Google spuckt auf die Schnelle nichts dazu aus.)

Das betrifft erstmal das Name Mangling (<-Google-Stichwort :-). C hat
eine typischerweise triviale Abbildung von Namen im Quelltext auf Namen
in der Objektdatei, so dass die meisten Programmiersprachen eine
Möglichkeit bieten, auf solche Namen zuzugreifen. In C++ wäre das
'extern "C"'.

Das ist aber nur einer von vielen Teilen, die kompatibel sein müssen. Da
wären noch z.B.
- Objektlayouts, vtbls, etc.
- wie findet 'throw' sein 'catch' und die zu zerstörenden Objekte?
- wie werden Parameter übergeben?

Ob und wie genau hier Compiler A das Verhalten von Compiler B imitiert,
um ein Zusammenlinken zu erlauben, weiß dann nur Compiler A. Die
Wahrscheinlichkeit ist bei C wieder höher, weil da nicht so viel Varianz
besteht (im Wesentlichen: gleiche Strukturlayouts, gleiche Definition
von Typen wie FILE oder time_t, aber nicht die ganzen komplizierten
C++-Eigenheiten).


Stefan

On 14 Okt., 17:22, Stefan Reuther <stefan.n...*arcor.de> wrote:
> Jens Lenge wrote:
> > sind Bibliotheksdateien (unter Windows z. B. ".lib", ".dll") eigentlich
> > compilerunabhängig "genormt"? Will sagen, kann eine mit Compiler A
> > erstellte LIB/DLL (unter dem gleichen OS) generell auch in einem mit
> > Compiler B erstellten Programm genutzt werden?
>
> Falls es hier eine "Norm" gibt, dann ist sie plattformabhängig.
>
> Unter Windows generieren z.B. Borland und Microsoft ihre .obj-Dateien
> und damit auch die .lib-Dateien in unterschiedlichen Formaten. Unter
> Linux wirst du mit einer DLL für ein libc5-System in einem libc6-
> Programm keine Freude haben.
>
> > (Ich habe dunkel in Erinnerung, dass das nur für Bibliotheken gilt, die
> > ausschließlich C-Funktionen, nicht aber C++-Elemente wie Klassen
> > exportieren. Aber dieses Halbwissen ist auch schon lange her, und Tante
> > Google spuckt auf die Schnelle nichts dazu aus.)
>
> Das betrifft erstmal das Name Mangling (<-Google-Stichwort :-). C hat
> eine typischerweise triviale Abbildung von Namen im Quelltext auf Namen
> in der Objektdatei, so dass die meisten Programmiersprachen eine
> Möglichkeit bieten, auf solche Namen zuzugreifen. In C++ wäre das
> 'extern "C"'.

Leider werden exportierte Klassen und deren Methoden in Studio und
Borland unterschiedlich codiert, zum Bsp:
Studio: ?toString*TZObject*Zeus_1**QBE?AVTString*2*XZ
Borland: *Zeus_1*TString*toString$xqv

> Das ist aber nur einer von vielen Teilen, die kompatibel sein müssen. Da
> wären noch z.B.
> - Objektlayouts, vtbls, etc.

Hier ist eines der Hauptprobleme: Der Speicher und damit the VTBLS
sind zum Beispiel bei Borland und Studio grund verschieden. Auch wenn
auf beiden Seiten Bibliotheken wie STL verwendet werden (die ist
übrigens auch nicht gleich, soviel zum "Standard"), können Objekte die
in der Borland Bibliothek erstellt werden, nicht in der Studio
Bibliothek gelöscht werden.

Abhilfe kann ein Framework dienen wie Zeus-Framework, welches
Schnittstellen zwischen den Bibliotheken verwendet.

> - wie findet 'throw' sein 'catch' und die zu zerstörenden Objekte?

Exceptions führen in den meisten Fällen zu unkontroliertem
Programmverhalten, und im besten Fall zu einem Absturz. Deshalb NIE
Exceptions über Bibliothek-Grenzen verwenden.

> - wie werden Parameter übergeben?

Hier kommt wieder das Speicherverwaltungsproblem zum Zug, wenn
komplexere Objekte übergeben werden. Primitive Datentypen
funktionieren im normalfall. Einzig wer den Stack abräumt muss geklärt
werden (normalerweise funktioniert __stdcall).

Eine Möglichkeit (von vielen) zeigt das Zeus-Framework auf (http://
www.xatlantis.ch/education/interfaces.html).