[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MOD - Development (http://www.emule-web.de/board/emule-mod-development/)
-   -   Compileren scheitert an der WS2_32.dll (http://www.emule-web.de/board/11993-compileren-scheitert-der-ws2_32-dll.html)

martin22 3. February 2007 13:45

Compileren scheitert an der WS2_32.dll
 
Das Compilieren der Source von Xtreme 5.4 (Unicode Release) mit Visual Studio 7.1 auf Win2K läuft zwar durch und erzeugt das emule.exe.

Dieses ist aber 6950912 Bytes gross und wenn man es startet gibt es die Fehlermeldung "FreeAddrInfoW" wurde in der DLL "WS2_32.dll" nicht gefunden.

Im Buildlog ist einzig folgendes aufgefallen:

MfcStaticBinaryCompatible.cpp
WINVER not defined. Defaulting to 0x0501 (Windows XP and Windows .NET Server)

LINK : warning LNK4235: /LTCG wurde angegeben, es ist jedoch keine Codeerstellung erforderlich. Entfernen Sie /LTCG von der Verknüpfungsbefehlzeile, um die Verknüpfungsleistung zu erhöhen.

LINK : warning LNK4089: Alle Verweise auf 'comdlg32.dll' wurden durch /OPT:REF verworfen

Was schafft Abhilfe?
Im voraus recht herzlichen Dank!


[edit by Pathfinder: Überschrift aussagekräftig gemacht! Siehe Board Rules und Checkliste vor dem Posten]

Xman 3. February 2007 14:11

Zitat:

Was schafft Abhilfe?
SP 1 installieren

martin22 9. February 2007 17:13

Leider noch immer Probleme beim Compilieren
 
Zitat:

Zitat von Xman
SP 1 installieren

Danke für den Hinweis, hab ich gemacht. Für Interessierte ein Direktlink:

http://download.microsoft.com/downlo...918007-X86.exe

Das erzeugte Exe ist dann 6'959'104 gross, während das heruntergeladene nur 5'689'344 auf die Waage bringt ??

Ausserdem verlangt es nach einer neuern debughelp.dll obschon es die Unicode-Release-Version sein soll??

Wie weiter?

Xman 9. February 2007 17:29

warum die nun bei Dir so viel größer ist versteh ich nicht.

Lad doch mal die neuste dbghelp.dll von MS runter und probier ob er die nimmt. Sag mir dann bescheid.

martin22 9. February 2007 18:49

Zitat:

Zitat von Xman
warum die nun bei Dir so viel größer ist versteh ich nicht.

Lad doch mal die neuste dbghelp.dll von MS runter und probier ob er die nimmt. Sag mir dann bescheid.

Jap er nimmt die vom VS 2005 und läuft :)
ABER:
Warum braucht ein Release das überhaupt??
Warum sooviel grösser??
Liegt das evt. an der immer noch erzeugten Warnung WINVER not defined. Defaulting to 0x0501 (Windows XP and Windows .NET Server) ??

Xman 9. February 2007 20:17

hast Du etwa mit VS 2005 compiliert ?
Und sag mir doch mal bitte die genaue Versionsnumemr der dbghelp.dll
Die Warnung kannst Du ignorieren.. ist eh keine Warnung sondern eher eine Info.

martin22 12. February 2007 09:21

Zitat:

Zitat von Xman
hast Du etwa mit VS 2005 compiliert ?
Und sag mir doch mal bitte die genaue Versionsnumemr der dbghelp.dll
Die Warnung kannst Du ignorieren.. ist eh keine Warnung sondern eher eine Info.

Mit VS 2005 kann mans nicht kompilieren, gibt jede Menge Fehler und Warnungen, also mein laufendes Eselchen ist mit VS 2003 SP1 erzeugt.

Die debughelp.dll im (laufend aktualisierten) Systemordner hat v. 5.00.2195.6613 - 160 KB und damit läuft der eigene Esel eben nicht, während der gesaugte geht!

Wenn ich die debughelp.dll vom VS 2005 (v. 5.1.2600.1106 - 479KB) ins Verzeichnis stelle dann läuft es ohne ersichtlichen Unterschied zum Original.

Aber es bleibt der erhebliche Grössenunterschied und die grundsätzliche Frage, warum eine Release-Version überhaupt ein debughelp.dll braucht??

Ist meine Vermutung, dass der hier Erzeugte trotz Einstellung auf Unicode-Release noch irgendwo Debug-Sachen reinlinkt, welche dann auch die Vergrösserung des Exe bewirken, nicht bestechend?

Wie würde man sowas rausfinden und abstellen?? Eigentlich müsste doch bei identischer Entwicklungsumgebung eine absolut identische exe Datei generiert werden??

Xman 12. February 2007 09:51

die dbghelp v. 5.1.2600.1106 ist auch diejenige die ich immer den binaries beilege. Wenn die auch bei VS 2005 beiliegt scheint sie also noch immer aktuell zu sein.
Diese Datei brauchst Du aber eigentlich nicht. Ihr einziger Zweck ist es im Falle eines crashes ein crashdump zu erzeugen.

Und ja... wenn Du die Xtreme-sources unverändert auf "Unicode release" compilierst sollte eine fast identische exe rauskommen. Fast, weil der Compiler noch eine Art Identifizierungscode in die exe schreibt um diese exe eindeutig zu anderen Files (z.b. emule.pdb) zuordnen zu können.

martin22 12. February 2007 13:52

Zitat:

Zitat von Xman
die dbghelp v. 5.1.2600.1106 ist auch diejenige die ich immer den binaries beilege. Wenn die auch bei VS 2005 beiliegt scheint sie also noch immer aktuell zu sein.
Diese Datei brauchst Du aber eigentlich nicht. Ihr einziger Zweck ist es im Falle eines crashes ein crashdump zu erzeugen.

Und ja... wenn Du die Xtreme-sources unverändert auf "Unicode release" compilierst sollte eine fast identische exe rauskommen. Fast, weil der Compiler noch eine Art Identifizierungscode in die exe schreibt um diese exe eindeutig zu anderen Files (z.b. emule.pdb) zuordnen zu können.

Sry ich hatte übersehen, dass in Deiner binary Disti die debughelp.dll dabei war...
Aber es bleibt der riesige Grössenunterschied. Um das einzugrenzen habe ich mal die Grössen der Libraries zum Vergleich gesammelt:

cryptlib.lib 29'654'300 Bytes
id3lib.lib 1'574'800 Bytes
pnglib.lib 332'638 Bytes
ResizableLib.lib 520'492 Bytes
sapi.lib 39'424 Bytes
CxImage.lib 1'042'862 Bytes
emule.lib 100'340 Bytes
zlib.lib 102'084 Bytes

8 Datei(en) 33'366'940 Bytes

Stimmen diese Grössen??

Wenn ich alle Libs lösche wird seltsamerweise die sapi.lib nicht neu erzeugt, wie macht man diese??

Dankeee!!

Xman 12. February 2007 14:19

die Größen stimmen.
Die sapi.lib wird nicht selbst erzeugt sondern stammt von MS und wird installiert wenn Du das MS Speech SDK installierst.

martin22 12. February 2007 18:40

Zitat:

Zitat von Xman
die Größen stimmen.
Die sapi.lib wird nicht selbst erzeugt sondern stammt von MS und wird installiert wenn Du das MS Speech SDK installierst.

Danke !! Jetzt krieg ich doch langsam den Überblick.
Analyse des Exe zeigt, dass meine Version sehr viel grösseren Code und Data hat. In Klammern die Werte des kleinern Original-Exe:

Linker Version: 7.10 (7.10)
Size of Code: 41 8000H (30 4000H)
Size of Initialized Data: 30 a000H (2e 5000H)
Address of Entry Point: 3917b3 (296f75)
Base of Data: 41 9000 (30 5000)

Ich kenn mich mit gcc viel besser aus als VC und merkwürdigerweise finde ich in den Proejekt-Einstellungen nix über Optimierungen. Könnte es sein dass da noch irgenwo ein Schalter falsch steht??

Xman 12. February 2007 19:37

gut möglich.. aber wieso nimmst Du nicht einfach die Projektdateien vom Xtreme ? Dann wären gleich alel Schalter wie bei mir gesetzt.

martin22 12. February 2007 22:34

Zitat:

Zitat von Xman
gut möglich.. aber wieso nimmst Du nicht einfach die Projektdateien vom Xtreme ? Dann wären gleich alel Schalter wie bei mir gesetzt.

Klar habe ich ich diese verwendet, aber jetzt in aller Ratlosigkeit eben auch rumgesucht, denn schliesslich muss es ja irgend was geben was diesen happigen Grössen-Unterschied bewirkt. Nachdem die Libs identische Grösse haben muss es imho mit den Optimierungen bezw. dem Linker an sich zusammenhängen??

Xman 12. February 2007 22:39

ich würd einfach mal probieren und ne andere Version runterladen und compilieren... oder auch mal den scarangel probieren.

martin22 14. February 2007 09:19

@Xman
 
Vielen Dank für die geduldige Unterstütztung. Tja es muss irgendwie an meinem VC liegen, denn auch andere OpenSource wird grösser :-(
Entweder hat M$ meine Schul-Version extra verstümmelt oder die vcproj legt nicht alle Schalter fest oder weiss der Teufel was...
Aber egal, das selber generierte Eselchen läuft und läuft...:clap :clap


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:24 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102