[wxWidgets | dlls] (Verständnis-?) Probleme beim Linken
-
Hallo zusammen,
ich versuche seit einigen Tagen ein wxWidget Programm lauffähig zu bekommen aber scheitere immer am Linker. (meistens an LNK2005, "(.lib) ... is already defined in .... (.lib)") Ich erläutere mal eben was ich in den letzten Tagen alles durchgeührt habe. Im Endeffekt haben auch einige Tage des lesens über dynamisches vs. statisches Linken, Debug vs. Release etc. nichts gebracht. Auch wenn ich jetzt weiss dass die Einstellungen aufeinander abgestimmt sein müssen fällt mir nicht ein welche Versuche ich jetzt unternehmen könnte.Zur Situation: Ich habe wxPack (wxWidgets 2.8.8) und entwickle mit VC++ 2005 Prof.
Vorneweg ist noch zu sagen dass sich die Probleme nicht direkt um wxWidgets drehen. Es dreht sich darum dass ich mein Hauptprogramm um folgende Plugin Architektur erweitern wollte.
http://www.nuclex.org/articles/building-a-better-plugin-architecture
Zuerst hatte ich alle Projektteile statisch /MT(d) gelinkt. Das mündet in einer lauffähigen Software welche aber dann bei Programmende mit _CrtIsValidHeapPointer(pUserData) einen Fehler wirft. Soweit meine Recherchen ergeben haben hängt dies mit verschiedenen Heaps zusammen was mich dazu zwingt meine Plugins und die Applikation /MD(d) zu linken. Korrekt?
Jetzt beginnt die Verwirrung. Muss ich jetzt alle teilhabenden Elemente dynamisch Linken? Den tue ich dies bekomme ich eine Meldung dass MSVCP80D.dll nicht vorhanden sei. Sammle ich die aus dem SxS Verzeichnis ein scheitert die Anwendung bei der Initialisierung mit 0x80000003.
Nebenbei geht es mir auch darum möglichst standalone zu sein, also möglichst keine wxWidget dlls mitliefern möchte. Allerdings gebe ich in meiner aktuellen Konfiguration keine expliziten wxWidget *.lib files an. Auch
Was mich momentan wohl extrem zurückwirft ist wohl dass ich auch nach einigen Tagen des nachlesens nicht wirklich verstanden habe was /MT vs /MD genau bedeutet. Was genau bedeutet dies für das betreffende und davon abhängige Projekte?
Ich kann gerne noch weitere Informationen geben falls es nötig ist. Möchte nur nicht direkt zu anfang jeden Leser mit nem riesigen Posting abschrecken
-
Generell solltest du die Runtime nicht statisch linken, sondern immer dynamisch. Das Redist-Package mit den nötigen DDLs wiegt grade mal 2-3 MB, das kann jeder User installieren.
wxWidgets kannst du dynamisch oder statisch linken, in deinem Fall wäre statisch besser, weil du ja keine DLLs mitgeben möchtest.
Da du aber Plugins entwickeln möchtest, MUSST du dynamisch linken, damit Plugin und Anwendung den selben Code verwenden können. Hier geht statisch leider nicht. Du kannst die ZAHL der DLL senken indem du als Monolithic kompilierst. Du musst zum linken in VS2005 übrigens keine .lib angeben, weil wxWidgets automatisch linkt, siehe MSVC.h in den wxWidgets-includes. Siehe auch Doku zu #pragma comment (lib, "foo.lib").Ich würde wie folgt vorgehen:
- wxWidgets selbst bauen und dabei eine monolithische DLL erstellen. Alles rauswerfen was nicht gebraucht wird, wie als bsp. TIFF-Support.
- Wenn du die Meldung bekommst, dass die funktion X bereits in mscrt.lib (beispiel) definiert ist, dann ignoriere diese .lib in den Linkereinstellungen.
- In den Präprozessoreinstellungen immer WXUSINGDLL angeben.
- Zu den Schaltern siehe bitte MSDN :), da steht das ganz gut.Muss ich jetzt alle teilhabenden Elemente dynamisch Linken? Den tue ich dies bekomme ich eine Meldung dass MSVCP80D.dll nicht vorhanden sei. Sammle ich die aus dem SxS Verzeichnis ein scheitert die Anwendung bei der Initialisierung mit 0x80000003.
Edit hier noch:
Du verteilst eine Debug Version deiner Anwendung. Die Debug-Runtime wird aber nur mit VS2005 installiert. Bitte die Anwendung als Release linken und dann das Redist-Package mit der C++-Runtime für 2005 auf dem Ziel-Computer installieren.
HTH
rya.
-
Dank dir bisher, ich bin gerade dabei nochmal sicher zu stellen dass ich auch alles richtig dynamisch linke.
Scorcher24 schrieb:
Generell solltest du die Runtime nicht statisch linken, sondern immer dynamisch. Das Redist-Package mit den nötigen DDLs wiegt grade mal 2-3 MB, das kann jeder User installieren.
Scorcher24 schrieb:
Ich würde wie folgt vorgehen:
- wxWidgets selbst bauen und dabei eine monolithische DLL erstellen. Alles rauswerfen was nicht gebraucht wird, wie als bsp. TIFF-Support.
- Wenn du die Meldung bekommst, dass die funktion X bereits in mscrt.lib (beispiel) definiert ist, dann ignoriere diese .lib in den Linkereinstellungen.
- In den Präprozessoreinstellungen immer WXUSINGDLL angeben.
- Zu den Schaltern siehe bitte MSDN :), da steht das ganz gut.Beissen sich diese beiden Aussagen nicht? Redistributable vs. selbst baun? Oder versteh ich dich da gerade falsch?
Muss ich jetzt alle teilhabenden Elemente dynamisch Linken? Den tue ich dies bekomme ich eine Meldung dass MSVCP80D.dll nicht vorhanden sei. Sammle ich die aus dem SxS Verzeichnis ein scheitert die Anwendung bei der Initialisierung mit 0x80000003.
Edit hier noch:
Du verteilst eine Debug Version deiner Anwendung. Die Debug-Runtime wird aber nur mit VS2005 installiert. Bitte die Anwendung als Release linken und dann das Redist-Package mit der C++-Runtime für 2005 auf dem Ziel-Computer installieren.
HTH
rya.[/quote]Na der Fehler tritt ja sogar bei mir selbst auf, ist dies normal so? Ich meine zumindest bei mir sollte die Anwendung ja laufen.
-
zu Punkt 1:
Nein, Redistributable heisst ja nur "verteilbar". Und damit meine ich nur die C++-Runtime von Visual Studio. wxWidgets hat keinen offiziellen Build der verteilt werden kann, da backt (leider in meinen Augen) jeder seine eigenen Brötchen.zu Punkt2:
Achso, ich dachte das ist auf einem anderen Rechner. Öhm installier mal bitte Visual Studio neu, wenn das geht, da scheinen sich die DLLs abgemeldet zu haben. Oder teste mal mit VC++ Express 2008, finde ich eh besser :P.
rya.
-
Phhhhhhhhew ... leck mich doch am A
Das war n hartes Stück arbeit aber ich glaube den Knackpunkt habe ich nun überwunden. Zumindest läuft jetzt ein mit wxVC erstelltes Standardprogramm dynamisch.Mal sehn ob es mir nun auch gelingt mein eigenes Projekt richtig aufzusetzen.