g++ erzeugt viel größere exe-Datei als cl

DAS ist eine gute Frage. Leider kann ich sie nicht beantworten
Ich mach einfach cl /EHsc prog.cpp.
Also zumindest treffe ich keine bewußte Entscheidung über den Linkvorgang ...

Kann ich unterstellen, daß OHNE statische Bindung die exe nicht auf einem System läuft, auf dem kein MS-Entwicklungssystem installiert ist?

Nö, kannst du nicht unterstellen. Weil du nur die DLLs mitliefern mußt oder der User eine VC Redistributable installieren muß, die es natürlich kostenlos von der MS-Homepage gibt.

@Bulli:
Ist schon klar, daß das 'zum Laufen kriegen' kein Problem darstellt. Wenn man aber so gar nix auf dem Zielrechner macht, könnte man auf diese Weise eben testen, ob die erstellte exe noch eine dll benötigt - aber natürlich kann diese dll schon auf irgendeine andere Weise auf das System gelangt sein.

Wenn ich folgende Ausführungen richtig verstehe:
http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
wird die Runtime - Bibliothek statisch gelinkt, sofern ich cl keine andere Option mitgebe ...

g++ erstellt auf den ersten Blick größere Dateien ja. Aber zähl mal zu der .exe vom M$-COmpiler die .pdb mit... schon bist fast genau so groß, aber mit dem vc immer noch unter dem g++..
Aber generell hast du recht. Die Dateien sind bei gleicher Linkage (dyn) vom g++ größer.

edit:
Nein, die Runtime wird beim VC immer dynamisch gelinkt, wenn man die IDE verwendet. Statisch muss extra gewählt werden.
rya.

Ich verwende nicht die IDE, sondern den Kommandozeilenbefehl cl ohne weitere Optionen. Wie ich den MSDN-Eintrag (s.o.) verstehe, wird dabei statisch gelinkt. Ich werde heute abend mal probieren, ob das stimmt, indem ich statische Bindung mit /MT explizit anfordere, und mal sehe, wie groß die exe dann wird.
Sollten beide exe-Versionen die CRT statisch angelinkt haben, bleibt es mir ein Rätsel, wieso die mit g++ erzeugte um sooooo viel größer ist ...

Belli schrieb:

Ich verwende nicht die IDE, sondern den Kommandozeilenbefehl cl ohne weitere Optionen. Wie ich den MSDN-Eintrag (s.o.) verstehe, wird dabei statisch gelinkt. Ich werde heute abend mal probieren, ob das stimmt, indem ich statische Bindung mit /MT explizit anfordere, und mal sehe, wie groß die exe dann wird.
Sollten beide exe-Versionen die CRT statisch angelinkt haben, bleibt es mir ein Rätsel, wieso die mit g++ erzeugte um sooooo viel größer ist ...

Ja, es stimmt. Wenn du auf der Kommandozeile kompilierst, wird das Zeug statisch gelinkt. Und mit der unterschiedlichen Größe hast du auch recht. cl erzeugt tatsächlich kleinere Exe-Files als g++.

@Scorcher24: Wen interessiert die pdb-Datei??? Das ist doch kein Argument, die viel zu großen Programme von g++ zu relativieren. Also ich habe dem benutzer noch nie die pdb-Datei mitgegeben.

Ich glaube, der Grund, wieso g++ das ganze so groß macht, ist, weil dort die ganze Standard-Runtime komplett reingelinkt wird, während cl so clever ist, nur das zu linken, was auch wirklich gebraucht wird. (Falls ich da falsch liege, bitte korrigieren.)

LordJaxom

X schrieb:

@Scorcher24: Wen interessiert die pdb-Datei??? Das ist doch kein Argument, die viel zu großen Programme von g++ zu relativieren. Also ich habe dem benutzer noch nie die pdb-Datei mitgegeben.

Da die pdb-Daten beim gcc in der exe enthalten sind, interessiert die Größe der pdb-Datei sehr wohl.

Warum interessieren sie, wenn der GCC selber schuld daran ist? Sollen sie diese Dateien aus der EXE nehmen, wenn sie für die Laufzeit nicht von Bedeutung sind.

Wenn jemand in sein Autokofferaum Betonplatten legt, habe ich auch keine Schuld daran, wenn ich ihm wegen optimierten Gewicht in meinem Auto davon fahre.

Komisch nur, das wenn MS in seine EXE irgendwas eingebaut hätte, MS ganz sicherlich die Nichtskönner gewesen wären.

@Topic: schon mal strip probiert? Ist glaube ich eine exe bei Mingw...

LordJaxom schrieb:

X schrieb:

@Scorcher24: Wen interessiert die pdb-Datei??? Das ist doch kein Argument, die viel zu großen Programme von g++ zu relativieren. Also ich habe dem benutzer noch nie die pdb-Datei mitgegeben.

Da die pdb-Daten beim gcc in der exe enthalten sind, interessiert die Größe der pdb-Datei sehr wohl.

Dann hat aber der gcc das Problem, dass diese Daten, die ja eigentlich nur für Debugzwecke sind, automatisch mitgelinkt werden und man sie nicht rausnehmen kann. Kann man sie doch rausnehmen (zum Beispiel mit strip), ist die Exe des gcc trotzdem noch weitaus größer als die des Visual C++ und die Frage, wieso das so ist, besteht immer noch.

So .... nun steht es fest:
Beide exe-Dateien werden statisch gelinkt, ohne weitere Optionen wird bei meinem aktuellen cpp-Test-Programm die g++ - Version ~10 mal so groß.
Mit Option -s immer noch ~5,5 mal so groß.

Im Büro heute hatte ich allerdings ein anderes Beispiel (pure c), wo die g++ - exe nur ca. 15KB groß wurde, cl hatte ich dort nicht zur Verfügung ...

Möglicherweise ist es also auch noch vom Programm selbst abhängig?

groovemaster

Belli schrieb:

So .... nun steht es fest:
Beide exe-Dateien werden statisch gelinkt

Hmmm, das wäre aber seltsam. MinGW unterstützt afaik noch kein statisches Linken. Schau mal nach, ob deine Binary msvcrt.dll bindet. Wenn nicht, dann verrate mir mal die genauen Compilerflags. Statisch zu linken versuche ich nämlich schon seit 'ner halben Ewigkeit, bisher ohne Erfolg.

groovemaster schrieb:

Belli schrieb:

So .... nun steht es fest:
Beide exe-Dateien werden statisch gelinkt

Hmmm, das wäre aber seltsam. MinGW unterstützt afaik noch kein statisches Linken. Schau mal nach, ob deine Binary msvcrt.dll bindet. Wenn nicht, dann verrate mir mal die genauen Compilerflags. Statisch zu linken versuche ich nämlich schon seit 'ner halben Ewigkeit, bisher ohne Erfolg.

Also ehrlich gesagt habe ich das bei MinGW einfach so unterstellt, bei dem MS - Compiler habe ich es ausprobiert, indem ich mal explizit mit /MT die exe erzeugt habe - die Dateigröße war identisch mit der der ohne den Schalter erzeugten exe.
Bei MinGW meine ich irgendwo gelesen zu haben, daß es immer statisch linkt (vielleicht schmeißt mein alzheimergeplagtes Gedächtnis das auch durcheinander und ich habe gelesen, daß es immer dynamisch linkt ...), außerdem habe ich das aus der riesigen Dateigröße geschlossen ...
Wenn Du mir verrätst, wie ich kontrollieren kann, ob das auch stimmt, will ich das gerne tun (wie kann ich sehen, ob meine Binary msvcrt.dll bindet?)
Als Flag habe nur -s benutzt ...

... wenn MinGW dynamisch linkt, dann ist das mit der großen exe-Datei ja noch unverständlicher ...

MinGW linkt auch nicht dynamisch. (Seit wann sind dessen Exe-Dateien bitteschön per default von einer speziellen DLL abhängig?)
Der Grund für die großen Exe-Dateien ist wie gesagt die Unfähigkeit von MinGW, die C++-Standardbibliothek bloß in Teilen zu linken. Sobald ein iostream oder sonst was gebraucht wird, klatscht er die gesamte Std-Lib rein. Deshalb sind die Programme so groß. Bei C ist das dann wohl cleverer geregelt.

Ja, ich habe mittlerweile den Eindruck gewonnen, daß reine C-Programme kleiner werden, als mit MS, C++ - Programme werden dagegen viel größer.

groovemaster

Belli schrieb:

Wenn Du mir verrätst, wie ich kontrollieren kann, ob das auch stimmt, will ich das gerne tun (wie kann ich sehen, ob meine Binary msvcrt.dll bindet?)

ZB mittels Dependency Walker. Falls du Total Commander benutzt, gibt es auch ein nettes Plugin namens fileinfo.

X schrieb:

Seit wann sind dessen Exe-Dateien bitteschön per default von einer speziellen DLL abhängig?

Grundsätzlich erstmal nicht. Sobald du aber bestimmte Funktionen der Standardbibliothek verwendest, wird die MS Runtime hinzugelinkt, und zwar dynamisch.