Frage

Ich muss etwas überprüfen, an dem ich Zweifel habe. Wenn eine gemeinsame Bibliothek (.dll) in C mit dem C99 -Standard geschrieben und unter einem Compiler zusammengestellt wird. Sag Mingw. Dann ist es meiner Erfahrung nach binär kompatibel und daher von jedem anderen Compiler verwendet. Sagen Sie Frau Visual Studio. Ich sage nach meiner Erfahrung, weil ich es mehr als einmal erfolgreich ausprobiert habe. Aber ich muss überprüfen, ob dies eine Regel ist.

Und außerdem möchte ich fragen, ob es tatsächlich so ist, warum Bibliotheken, die vollständig in C geschrieben wurden, wie OpenCV beispielsweise nicht kompilierte Binärdateien für jedes verschiedene Betriebssystem bereitstellen? Ich weiß, dass der offensichtliche Grund darin besteht, alle Parameter für Kompilierzeit festzulegen, aber ansonsten gibt es keine, oder?

Bearbeiten: Ich füge eine zusätzliche Frage hinzu, die ich dem Original als logische Erweiterung sehe. Ist es nicht so, wie man eine Bibliothek für geschlossene Quellen erstellen würde? Da die Möglichkeit, dort aus dem Fenster zu sein, die Möglichkeit gibt, ist das Angeben von Binärdateien die einzige Wahl. In diesem Fall ist das Bereitstellen von Binärdateien für möglichst viele Architekturen das gewünschte Ergebnis, wobei C eine offensichtliche Wahl für die beste Portabilität zwischen Systemen und Compilern ist. Recht?

War es hilfreich?

Lösung

Im speziellen Fall von C -Compilern (MSVC und GCC/Mingw) in der Windows -Welt sind Sie bei der Annahme einer binären Kompatibilität korrekt. Man kann eine von GCC zusammengestellte C -Schnittstelle mit einem Programm in Visual Studio verknüpfen. Auf diese Weise können C99 -Projekte wie FFMPEG Entwicklern die Anwendung mit Visual Studio schreiben. Man muss nur die Importbibliothek mit lib.exe erstellen, die in der Microsoft Toolchain von der DLL gefunden werden. Oder umgekehrt mit Mingw.orgs Pexports oder besser, Gendef von Mingw-W64, kann man eine GCC-Import-LIB für eine MSVC-produzierte DLL erstellen.

Diese praktische Interoperabilität bricht zusammen, wenn Sie in die C ++ - Schnittstellenwelt eintreten, in der der ABI von MSVC und GCC unterschiedlich und inkompatibel ist. Es kann funktionieren, es darf keine Garantien unternommen werden und es werden keine Anstrengungen unternommen, um dies zu ändern. Außerdem ist das Debugging -Informationen offensichtlich anders, bis jemand einen Debug -Informationsgenerator/-autor in GCC schreibt, der mit dem Debugger von MSVC kompatibel ist (natürlich zusammen mit der GDB -Unterstützung).

Ich glaube nicht, dass C99 etwas speziell für Funktionen für Funktionen oder die Art und Weise verändert, wie Argumente in Symboldefinitionen behandelt werden. Auch hier sollte es hier auch kein Problem geben.

Beachten Sie, dass es, wie Vijay sagte, immer noch den Architekturunterschied gibt, sodass eine X86 -Bibliothek bei der Verknüpfung mit einer AMD64 -Bibliothek nicht verwendet werden kann.


Um auch Ihre zusätzliche Frage zu Binärdateien geschlossener Quelle zu beantworten und eine Version für alle verfügbaren Compiler/Architekturen zu verteilen.

Genau so würden Sie eine Binärquelle für geschlossene Quellen erstellen. Zusätzlich zur Importbibliothek ist es auch sehr wichtig, Exporte vor der DLL zu verbergen und die DLL selbst für die Verknüpfung unbrauchbar zu machen (wenn Sie nicht möchten, dass Client -Code private Funktionen in der Bibliothek verwenden, siehe zum Beispiel die Ausgabe von dumpbin /exports Auf einer Msoffice -DLL, viele versteckte Sachen dort). Sie können dasselbe mit GCC (glaube ich, nie benutzt oder ausprobiert) mit Dingen wie erreichen __attribute(hidden) etc...

Einige Compiler -spezifische Punkte:

  1. MSVC wird mit vier (eigentlich nur drei verbleibenden in neueren Versionen) verschiedene Laufzeitbibliotheken über /mt, /md und /ld geliefert. Darüber hinaus müssten Sie einen Build für jede Version von Visual Studio (einschließlich Service Packs) bereitstellen, um die Kompatibilität zu gewährleisten. Aber das ist Binärquelle und Fenster für Sie ...

  2. GCC hat dieses Problem nicht; Mingw links immer zu msvcrt.dll bereitet von Windows (da Windows 98) bereitgestellt wird, entspricht /MD (und möglicherweise auch einer Debug -Bibliothek, die mit /mdd entspricht). Aber ich gibt es zwei Versionen von Mingw (mingw.org und Mingw-w64), die keine binäre Kompatibilität garantieren. Letzteres ist vollständiger, da es 64-Bit-Optionen sowie 32-Bit-Optionen bietet und einen vollständigeren Header/Bibliothekssatz (einschließlich eines beträchtlichen Teils von DirectX und DDK) bietet.

Andere Tipps

Die allgemeine Regel lautet, wenn Ihre OS/CPU -Kombination über einen Standard -ABI verfügt und dass dieser ABI für Ihre Sprache leistungsfähig genug ist, folgen die meisten Compiler diesem ABI und dadurch binär kompatibel, sodass Sie Bibliotheken verknüpfen (freigegeben oder statisch) mit verschiedenen Compilern zu Programmen zusammengestellt, die mit anderen Compilern gut zusammengestellt wurden.

Das Problem ist, dass die meisten ABIs ziemlich schwach sind-sie sind für Sprachen auf niedrigem Niveau wie C und Forran gestaltet und stammen bis zu den Tagen vor objektorientierten Sprachen wie C ++ zurück. Daher fehlt ihnen tendenziell Unterstützung für Dinge wie Funktion Überlastung, benutzerdefinierte Operatoren, Ausnahmen, globale Conctortoren und Zerstörer, virtuelle Funktionen, Vererbung und so, die von C ++ benötigt werden.

Dieser Mangel wurde erkannt, als C ++ entworfen wurde, weshalb C ++ hat extern "C" - Damit sich der Compiler für bestimmte Funktionen auf den Standard-ABI beschränkt, während alle zusätzlichen C ++- Funktionen, die der ABIS im Allgemeinen nicht unterstützt, deaktiviert.

Eine gemeinsame Bibliothek oder DLL, die mit einer bestimmten Architektur zusammengestellt wurde, kann mit Anwendungen verknüpft werden, die von anderen Compilern zusammengestellt werden, die auf dieselbe Architektur abzielen. (Mit Architektur meine ich eine Prozessor/Betriebssystem -Kombination). Für einen Bibliotheksentwickler ist es jedoch nicht praktikabel, sich gegen alle möglichen Architekturen zusammenzustellen. Wenn eine Bibliothek in Quellform verteilt ist, können Benutzer auch Binärdateien erstellen, die auf ihre spezifischen Anforderungen optimiert werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top