Probleme mit statischer Bibliothek im Debug-Modus

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Nexus

Aber wie macht man das am besten, wenn man eine statische Bibliothek zur Verfügung stellen will? Kommt man da nicht drum herum, alle 4 möglichen Kombinationen von Konfigurationen (Debug/Release - CRT statisch/dynamisch gelinkt) einzurichten?

Oder reicht es, nur auf Debug/Release Rücksicht zu nehmen und z.B. gegen statisch gegen die CRT zu linken?

Fusel.Factor

Mach doch einfach verschiedene ProjectDateien.
So habe ich es bis jetzt immer gehandhabt und hatte keine Probleme damit.

Nexus

Welche Dateien meinst du?

Momentan stelle ich zwei Bibliotheken (.lib) pro Projekt zur Verfügung, also für Debug- und Releasemodus. Soll ich total 4 pro Projekt erzeugen, um auch noch die CRT-Linkage zu berücksichtigen?

Martin Richter

1. Das ignorieren der Default Libs ist meistens nicht das Problem.
Diese Meldungen passieren fast immer nur, wenn es zwei Objekt Module gibt, die mit unterschiedlichen CRT Enstellungen kompiliert wurden zusammen gelinkt werden.
Es ist nie gut NODEFAULTLIB zu verwenden. Korrekt ist es mit /VERRBOSE das schuldige Objekt Modul zu finden.
2. Ich halte pragmas comment lib immer für den besseren Weg.

Nexus

Okay, momentan habe ich es so gelöst, dass beim Linken mit der falschen CRT-Version über #error ein Fehler ausgelöst wird. Doch so wird der Anwender gezwungen, dynamisch gegen die CRT zu linken.

Jetzt habe ich 2 statische Bibliotheken pro Projekt (Debug/Release). Wenn ich eine statische Linkage gegen die CRT auch ermöglichen will, komme ich nicht darum herum, total 4 Libs zu erstellen?

Badestrand

Nexus schrieb:

Jetzt habe ich 2 statische Bibliotheken pro Projekt (Debug/Release). Wenn ich eine statische Linkage gegen die CRT auch ermöglichen will, komme ich nicht darum herum, total 4 Libs zu erstellen?

Kann man dann eigentlich so eine Header-Datei machen:

#ifdef _DEBUG
#    ifdef _DLL
#       pragma comment( lib, "bla_debug_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_debug_static_crt.lib" )
#    endif
#else
#    ifdef _DLL
#       pragma comment( lib, "bla_release_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_release_static_crt.lib" )
#    endif
#endif

? Oder wie wird das normalerweise gemacht, manuell die Bibliothek angeben lassen? Gibt's bei so 'ner Header-Datei Nachteile?

edit: Das hier ginge auch

#ifdef _DEBUG
#    define LIBINC_DBG_REL "debug"
#else
#    define LIBINC_DBG_REL "release"
#endif

#ifdef _DLL
#    define LIBINC_STAT_DYN "dynamic"
#else
#    define LIBINC_STAT_DYN "static"
#endif

#pragma comment( lib, "bla_" LIBINC_DBG_REL "_" LIBINC_STAT_DYN ".lib" )
#undef LIBINC_DBG_REL
#undef LIBINC_STAT_DYN

Nexus

Ja, momentan hab ichs aber eben auf dynamische CRT-Linkage eingeschränkt, um zwei verschiedene Konfigurationen zu vermeiden:

#ifndef _DLL
 #error Muss dynamisch gegen die CRT gelinkt werden.
#endif

#ifdef _DEBUG
 #pragma message("Automatisches Linken mit Fraction-d.lib (Debug)")
 #pragma comment(lib, "Fraction-d.lib")
#else
 #pragma message("Automatisches Linken mit Fraction.lib (Release)")
 #pragma comment(lib, "Fraction.lib")
#endif

Also besteht die einzige Möglichkeit doch darin, vier statische Bibliotheken bereitzustellen?

Nexus

Sorry, wenn ich die Frage zum fünften Mal stelle
Gibt es keine andere Möglichkeit, als 4 statische Bibliotheken (.lib) zu erstellen, wenn man sowohl dynamische als auch statische CRT-Linkage und auch Debug- und Release-Modus ermöglichen will?

Badestrand

Nexus schrieb:

Gibt es keine andere Möglichkeit, als 4 statische Bibliotheken (.lib) zu erstellen, wenn man sowohl dynamische als auch statische CRT-Linkage und auch Debug- und Release-Modus ermöglichen will?

Ich bin mir zumindest relativ sicher, dass es nicht anders geht. Nicht zu vergessen, diese 4 Libs übrigens ja nur pro Compilerversion

Nexus

Badestrand schrieb:

Nicht zu vergessen, diese 4 Libs übrigens ja nur pro Compilerversion

Und ich dachte, statische Bibliotheken wären ein guter Weg zur Wiederverwendung von Code...

Wahrscheinlich werde ich den Benutzer einfach zwingen, MSVC++ mit dynamischer CRT-Linkage zu verwenden...

Aber wie ist das bei anderen Bibliotheken, z.B. Boost, gelöst? Gibt es da für alle existierenden Compiler eigene Libs?

Martin Richter

Nein! Es gibt IMHO keine andere Möglichkeit.
Statisch/Dynamisch, Debug/Non-Debug macht leider 2x2=4
Und das je Compiler Version...

Nexus

Okay, danke für die Antworten.
Dann werd ich mir das halt wohl oder übel antun müssen.

Naja, so viel zu Code-Wiederverwendung... Irgendwie beschleicht mich das Gefühl, eine eigene CPP-Datei statt einer Lib mitzuliefern wäre einfacher...

Martin Richter

Nexus schrieb:

Naja, so viel zu Code-Wiederverwendung... Irgendwie beschleicht mich das Gefühl, eine eigene CPP-Datei statt einer Lib mitzuliefern wäre einfacher...

Warum lieferst Du nicht eine DLL aus, und dazu eine Import-LIB?

Nexus

Martin Richter schrieb:

Warum lieferst Du nicht eine DLL aus, und dazu eine Import-LIB?

Aber für die Import-Lib hätte man wieder das gleiche Problem, oder?

Martin Richter

Eben nicht! Die enthält keinen Code, sondern nur Referenzen auf die DLL.

Wichtig ist dann aber, dass aber Schnittstelle nicht geschludert wird und nicht mit STL Containern und CString etc, gearbeitet wird.
Was glaubst Du wie die Anbindung an die MS API erfolgt? Die ist komplett Compiler unabhängig.

Nexus

Okay, danke.

Aber nicht mit der STL zu arbeiten, empfinde ich als starke Einschränkung... Zu was verliert man Kompatibilität, wenn man sie doch einsetzt?

Nexus

Wäre noch aktuell...

Was darf man beim Verwenden eigener DLLs nicht verwenden und weshalb nicht, und zu was verliert man die Kompatibilität, wenn man es doch tut?

Badestrand

Nexus schrieb:

Was darf man beim Verwenden eigener DLLs nicht verwenden und weshalb nicht, und zu was verliert man die Kompatibilität, wenn man es doch tut?

Soweit ich weiß darf die Schnittstelle nur Builtins enthalten, nicht mal Structs (evtl unterschiedliches Padding) und schon gar keine Klassen (evtl alles unterschiedlich).

edit: Wie macht das eigentlich die WinAPI mit structs? edit2: => Ich hab Unrecht

Martin Richter

PODs gehen in Ordnung. Auch Zeiger zur Not, wenn klar ist wer sie wieder frei gibt.
In der WinAPI wird das Padding (pragma pack) im Header mit angegeben.

Die STL ist ganz klar etwas was man unbedingt meiden muss, denn der Austausch hier ist dann immer Compiler abhängig. Das binäre Format ändert sich eben.
Solch eine DLL (auch als Import,DLL) könnte man nie zwischen mehreren Compiler Versionen verwenden und das ist ja eigentlich der Sinn von DLLs, dass diese unabhängig sein sollen.

Natürlich: Sie müssen es nicht! Unsere Applkation wird auch mit Kern-DLLs ausgeliefert, die immer zusammen mit der EXE gebaut werden und nie einzeln getauscht werden.