F
Bezüglich verschiedener Compiler sei auch noch erwähnt, dass diese abseits von unterschiedlichem Name Mangling auch noch teilweise verschiedene Implementationen oder Versionen der Standardbibliothek verwenden, oder Objekte ein anderes Speicherlayout haben können. Virtuelle Vererbung kann z.B. sehr unterschiedlich implementiert sein, und auch bezüglich Padding lässt der Standard diverse Freiheiten, wie ein Objekt letztendlich exakt im Speicher aussieht.
Das alles führt zu der Problematik, dass Programme sehr wahrscheinlich nicht mit dynamischen C++-Bibliotheken funktionieren werden, wenn diese mit einem anderen Compiler gebaut wurden (oder teilweise auch mit dem selben Compiler und nur mit anderen Compiler-Einstellungen), es sei denn man beschränkt sich auf ein minimales C-Interface und verwendet an der Schnittstelle lediglich POD-Strukturen.
Das bedeutet z.B. keine Bibliotheksfunktionen, die beispielsweise einen std::string , std::vector oder ähnliches als Parameter entgegennehmen, nicht einmal selbtgebaute Klassen wenn man wirklich maximale Kompatibilität sicherstellen will. Der Grund dafür ist, dass innerhalb der mit Compiler B gebauten Bibliotheksfunktion ein anderes Spiecherlayout oder gar einer völlig andere Implementierung des übergebenen Objekts erwartet wird, als der mit Compiler A gebaute Programmcode konstruiert hat und der Bibliotheksfunktion übergibt.
Davon abgesehen - wenn man akzeptiert dass Programm(e) und Dynamische Bibliotheken immer eine Einheit bilden, und gemeinsam mit dem selben Compiler und identischen Flags kompiliert werden müssen, funktionert das meiner bisherigen Erfahrung nach plattform- und systemübergreifend recht gut und ohne viel Kopfzerbrechen. Zu deiner Frage 2.: Ich gehe davon aus, dass dieses CMake-Konstrukt "plattformunabhängig" funktioniert, zumindest für alle Plattformen und Compiler die von CMake unterstützt werden. Mit CMake habe ich damit zumindest unter Linux und Windows mit MSVC, GCC und Clang bisher noch keine gegenteiligen Erfahrungen gemacht.
Finnegan
