DLL sauber releasen

Danke, das werde ich so machen. Gibt es, abgesehen vom Namen, eigentlich eine Möglichkeit festzustellen, ob eine Library im Debug oder Release-Mode gemacht wurde?

Hintergrund der Frage: Das VS2008-Projekt baut die DLL im Debug- und Releasemode. Aber wenn ein Beispielcode im Debug-Mode compiliert und gegen die Debug-DLL gelinkt wird, stürzt er mit einem Memory-Problem ab, und zwar dort, wo über Vektoren iteriert wird. Daher nehme ich an, daß es am unterschiedlichen Memory-Footprint der STL liegt und die vermeintliche Debug-DLL in Wahrheit eine Release-DLL sein könnte, obwohl sie im Debug-Mode gebaut wurde.

hustbaer

Guck mit dem Dependency-Walker

http://www.dependencywalker.com/

gegen welche CRT DLL die fragliche DLL gelinkt ist.

theliquidwave

ReleaseCandidate schrieb:

Gibt es, abgesehen vom Namen, eigentlich eine Möglichkeit festzustellen, ob eine Library im Debug oder Release-Mode gemacht wurde?

Ich würde behaupten, dass die Debugversion quasi immer größer ist als die Release-Version.

Die DLL läuft nativ, ich denke, eine CRT gibt es in dem Fall nicht, oder? Ich komme aus der Linux-Welt, daher die Fragen, Visual Studio verwende ich kaum. Die angebliche Debug-Version ist 202 kB groß, die Release-Version 181 kB. Dependency-Walker zeigt unter der Library an:

Kernel32.dll
MSVCP90.dll
MSVCR90.dll

und unter Module:

API-MS-WIN-CORE-[whatever].dll
Kernel32.dll
Kernelbase.dll
MSVCP90.dll
MSVCR90.dll
MSVCR90.dll
MSVCRT.dll
NTDLL.dll

hustbaer

MSVCP90.dll und MSVCR90.dll sind die Release DLLs.
Die Debug-Versionen wären MSVCP90D.dll und MSVCR90D.dll.

ReleaseCandidate schrieb:

Die DLL läuft nativ, ich denke, eine CRT gibt es in dem Fall nicht, oder?

Doch, CRT hast du eigentlich immer.

hustbaer schrieb:

MSVCP90.dll und MSVCR90.dll sind die Release DLLs.
Die Debug-Versionen wären MSVCP90D.dll und MSVCR90D.dll.

Sehr arg. Die DLL wurde im Debug-Mode Win32 gebaut. Woran kann das denn liegen?

Ich habe jetzt cout << sizeof(..) für verschiedene Typen in die Library eingebaut und mit dem sizeof(..) der gleichen Typen im Beispielcode verglichen. Resultat:

Debug-Library: sizeof(vector<..>)=24
Debug-Beispiel: sizeof(vector<..>)=20

Debug-Library: sizeof(set<..>)=32
Debug-Beispiel: sizeof(vector<..>)=28

Die STL-Typen der Library sind größer. Obwohl beides als Win32 Debug gebaut wurde. Ich muß mal die Compiler- und Linker-Flags vergleichen, vielleicht ist da was zu finden... Nehme Hinweise gerne engegen.

ReleaseCandidate schrieb:

Die DLL läuft nativ, ich denke, eine CRT gibt es in dem Fall nicht, oder?

Doch, CRT hast du eigentlich immer.[/quote]

Dachte, die CRT ist nur für managed Code. Wie soll die heißen?

Herr! Ich glaube, ich habe es gerade selbst gefunden:

#define _HAS_ITERATOR_DEBUGGING 0

löst das Problem. Die Frage ist nur, warum der eine Code mit und der andere ohne Iterator-Debugging compiliert wurde. Ich habe da explizit nichts gesetzt.

theliquidwave

CRT = C Run-Time

hustbaer

ReleaseCandidate schrieb:

Dachte, die CRT ist nur für managed Code. Wie soll die heißen?

Wie soll wer/was heissen?
MSVCR90.dll ist die CRT.

Und das andere, das mit managed, wäre die .NET Runtime.

Ah, C-Runtime... Ich dachte, CRT steht für common language runtime, also eine Bibliothek für eine virtuelle Maschine.

Hustbär hat's ja eigentlich schon gesagt, aber ich habs nicht gleich verstanden: Der Fehler war, daß die falsche Runtime mit der DLL gelinkt wurde, ich habe im Menü den Unterschied zwischen Multithreaded DLL und Multithreaded Debug DLL übersehen. Diese Dinge sind verdammt schwer zu debuggen, aber sowas passiert einem nur einmal. Danke für die Hilfe.

hustbaer

ReleaseCandidate schrieb:

Ich dachte, CRT steht für common language runtime

Ne, die common language runtime ist die CLR. Ist auch ganz logisch. Anfangsbuchstaben und so

Diese Dinge sind verdammt schwer zu debuggen, aber sowas passiert einem nur einmal.

Hihi.
Ja, meint man. Bis es einem ein 2. mal passiert.
(Und dann denkt man sich: ARGH!!!, das passiert mir aber sicher nur 2 mal!!! Bis... :D)