Уважаемые!
Не подскажите, как заставить gcc делать не такое здоровое консольное приложение. Если компилю WindowsGUI, то размер нормальный. А вот консольные приложения- ужас! Поскажите лечение данной проблемы!
Спасибо.
1. В опциях компилятора
— отключить генерацию отладочной информации (generate debugging information),
— включить strip executable.
2. Использовать C библиотеки вместо C++.
Например, этот код у меня (wxDevCpp / MinGW) компилируется в 5.632 байт:
#include <stdio.h>
int main()
{
printf("Hello World!\n");
getchar();
}
А этот — в 266.240 байт:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world!\n";
getchar();
}
Если оставаться в рамках C++, то приемлемого решения с GCC / MinGW я не вижу. Только пробовать другой компилятор. Borland C++ 5.5 (BCC32), например, справляется уже заметно лучше. Второй пример превращается в 113.152 байт. Надо еще посмотреть, какие у него там установки по умолчанию, может еще меньше можно сделать.
Надеюсь, откликнутся еще более опытные коллеги. У меня самого пока очень поверхностное представление о C++.
Ну и свой код приведи, что ли.
Re[2]: gcc + console = 256512 byte
От:
Аноним
Дата:
29.05.06 21:36
Оценка:
Код приводить смысла нет- он такой же как и вышеприведённый.
Компилю из CodeBlocks. Получается 257000 (примерно). Ключи для минимального размера установил. Никакой дебаг-инфо и т.п.
strip.exe не уменьшает размер ни на байт.
Где-то слышал, что вместо статической линковки стандартной библиотеки можно прикрутить msvcrt.dll. Только как?
A>strip.exe не уменьшает размер ни на байт.
Значит уже компилируется с параметром -s (передается линкеру через компилятор)
А>Где-то слышал, что вместо статической линковки стандартной библиотеки можно прикрутить msvcrt.dll. Только как?
да он и так линкуется (посмотри зависимости в exe). Только вот, насколько я понимаю, внутри msvcrt.dll находятся только C библиотеки, а iostream и прочих от C++ там нет. Может, внутри msvcp**.dll есть?
Видимо GCC вставляет iostream целиком в EXE, что и приводит к резкому разбуханию файла. Другие компиляторы, наверное, умеют разбить эту библиотеку на части и вставить только то, что действительно нужно.
Во всяком случае, BCC32 не линкует никакие внешние C/C++ библиотеки, т.е. у него iostream тоже находится внутри результирующего exe, но в более компактном виде. Кстати, в случае чистого C это приводит к большему размеру EXE — где то от 50 kb — по сравнению с GCC, но в принципе должно обеспечивать бОльшую стабильность (т.к. независим от версии msvcrt.dll).
Many people are surprised by how big executables are, especially if the source code is trivial. For example, a simple "hello world" program can generate an executable that is larger than most people expect (40+K bytes).
One reason executables can be large is that portions of the C++ runtime library might get statically linked with your program. How much gets linked in depends on compiler options regarding whether to statically or dynamically link the standard libraries, on how much of it you are using, and on how the implementer split up the library into pieces. For example, the <iostream> library is quite large, and consists of numerous classes and virtual functions. Using any part of it might pull in nearly all of the <iostream> code as a result of the interdependencies (however there might be a compiler option to dynamically link these classes, in which case your program might be small).
Another reason executables can be large is if you have turned on debugging (again via a compiler option). In at least one well known compiler, this option can increase the executable size by up to a factor of 10.
You have to consult your compiler manuals or the vendor's technical support for a more detailed answer.
Только из нее непонятно, где же брать готовую библиотеку, к которой можно линковаться, и какими опциями компилятора этого можно достичь.
S>Попробуй флаг -Os
Optimize for space rather than speed
Не помогает, размер результирующего exe в примере выше получается точно таким же. Вообще никакие опции оптимизации не помогают.
Здравствуйте, ArtDenis, Вы писали:
AD>Думаю, что пока у GCC не появиться хорошего оптимизатора, а линкер не AD>научится убирать неиспользуемый код, решить эту проблему не удастся.
Спорное заявление. Когда гуёвое приложение делаю -не очень большое, но классов порядка 20 штук+ в каждом от 10 до 50 методов(обёртки для HWND и прочего) + <vector>- то размер экзешника даже меньше размера экзешника от VC7 (release конечно-же).
Может тогда действительно научиться линковать внешние библиотеки? Как кандидаты мне видятся msvcp50.dll, msvcp60.dll, msvcp71.dll; mfc40.dll, mfc40u.dll, mfc42.dll, mfc42u.dll. Или может есть какие не от MS?
Научил бы кто, как правильно это делать...
Аноним пишет: > Не подскажите, как заставить gcc делать не такое здоровое консольное приложение. Если компилю WindowsGUI, то размер нормальный. А вот консольные приложения- ужас! Поскажите лечение данной проблемы!
Должно немного помочь (натравливать на скомпилённый exe-шник):
Здравствуйте, ArtDenis, Вы писали:
AD>Должно немного помочь (натравливать на скомпилённый exe-шник): AD>
AD>strip --strip-all test.exe
AD>
Так это как раз после стрипанья у него размер 250 кб получается. Без этого около 480 (с дебаг-инфо и т.п.). Может дело в реализации STL? Реально ли STL от VisualC прикрутить?
Здравствуйте, Lab74, Вы писали:
L>Может тогда действительно научиться линковать внешние библиотеки? Как кандидаты мне видятся msvcp50.dll, msvcp60.dll, msvcp71.dll; mfc40.dll, mfc40u.dll, mfc42.dll, mfc42u.dll. Или может есть какие не от MS? L>Научил бы кто, как правильно это делать...
ИМХО правильно — использовать MSVC. Все эти либы для него родные, стало быть и проблем нет. C++ HelloWorld (с динамичеси прилинкованными либами) компилируется в 7K.
MinGW может быть оправдан в случае использования каких-то заточенных под GCC библиотек, других преимуществ у него нет. Компиляторы MSVC 2003 и 2005 доступны бесплатно. Качество генерируемого кода (на мой взгляд) обычно лучше. Если же использовать API виндовс — у MinGW могут возникнуть проблемы с заголовочными файлами.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
GN>ИМХО правильно — использовать MSVC. Все эти либы для него родные, стало быть и проблем нет. C++ HelloWorld (с динамичеси прилинкованными либами) компилируется в 7K.
Т.е. приведенный выше С++ пример Hello World (с iostream) компилируется в 7 kb?
И к какой dll он линкуется? --> Просьба привести опции компиляции (лучше всего — командную строку целиком).
Я использовал компилятор от 2005й студии — msvcr80.dll (CRT) и msvcp80.dll (C++ lib). В раних версиях цыфры в именах dll будут другие.
-->> Просьба привести опции компиляции (лучше всего — командную строку целиком).
cl /MD /EHsc /Ox filename.cpp
/MD говорит, что нужно линковать с dll.
В IDE это меняется в свойствах проекта: C++ -> Code Generation -> Runtime Library
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Я использовал компилятор от 2005й студии — msvcr80.dll (CRT) и msvcp80.dll (C++ lib). В раних версиях цыфры в именах dll будут другие.
-->> Просьба привести опции компиляции (лучше всего — командную строку целиком).
cl /MD /EHsc /Ox filename.cpp
/MD говорит, что нужно линковать с dll.
В IDE это меняется в свойствах проекта: C++ -> Code Generation -> Runtime Library
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, ArtDenis, Вы писали:
А>Так это как раз после стрипанья у него размер 250 кб получается. Без этого около 480 (с дебаг-инфо и т.п.). Может дело в реализации STL? Реально ли STL от VisualC прикрутить?
а смысл, размер скорее всего еще больше получится, т.к. эта STL уж точно не будет использовать нестандартные расширения gcc
Здравствуйте, ArtDenis, Вы писали:
AD>Думаю, что пока у GCC не появиться хорошего оптимизатора, а линкер не AD>научится убирать неиспользуемый код, решить эту проблему не удастся.
Так вроде там давно инкрементный линкер, а компилятор умеет оптимизировать код
как по скорости, так и по размеру.
Здравствуйте, Аноним, Вы писали: А> Может дело в реализации STL? Реально ли STL от VisualC прикрутить?
Здравствуйте, mr_jek, Вы писали: _>а смысл, размер скорее всего еще больше получится, т.к. эта STL уж точно не будет использовать нестандартные расширения gcc
что понимается (вы понимаете) под STL? в каком виде оно существует (исходники, DLL etc.)
(Только прошу, не надо отвечать ссылками, ответьте лучше здесь своими словами)
Входит ли iostream (из обсуждаемого примера) в STL? Если нет, то зачем здесь упоминается STL?
Какие нестандартные расширения GCC имеются ввиду? (Надеюсь, туда не относится iostream?)
