g++ создает большие двоичные файлы, несмотря на небольшой проект

Question

Наверное, это общий вопрос.На самом деле, кажется, я спрашивал об этом много лет назад...но я не могу вспомнить ответ.

Проблема в:У меня есть проект, состоящий из 6 исходных файлов.Все они не более 200 строк кода.Он использует множество контейнеров STL, stdlib.h и iostream.Теперь размер исполняемого файла составляет около 800 КБ....Думаю, мне не следует статически связывать библиотеки.Как это сделать с помощью GCC?А в Eclipse CDT?

РЕДАКТИРОВАТЬ:Поскольку я отвечаю далеко от того, что хочу, я думаю, что это повод для разъяснения.Что я хочу знать, так это почему такая маленькая программа имеет такой большой размер и какова связь со статическими, разделяемыми библиотеками и их различиями.Если это слишком длинная история, не стесняйтесь давать ссылки на документацию.Спасибо

Answer 1

Если вы дадите имена динамических библиотек g++ и не передадите -static флаг, он должен связываться динамически.

Чтобы уменьшить размер, вы, конечно, можете strip двоичный файл и передать -Os (оптимизировать по размеру) флаг оптимизации g++.

Answer 2

Следует помнить, что использование STL приводит к появлению дополнительного кода. в вашем исполняемом файле даже если вы динамически связываетесь с библиотекой C++.Это связано с тем, что STL представляет собой набор шаблоны которые на самом деле не компилируются, пока вы не напишете и не скомпилируете свой код.Поскольку библиотека не может предвидеть, что вы можете хранить в контейнере, она не может уже содержать код для этого конкретного использования контейнера.То же самое касается алгоритмов и всего остального в STL.

Я не говорю, что это определенно причина того, что ваш исполняемый файл намного больше, чем вы ожидаете.Но это может быть фактором.

Answer 3

По умолчанию Eclipse должен выполнять динамическую компоновку, если только вы не установили статический флаг для компоновщика в вашем make-файле.

В ответ на ваше EDIT:

- когда вы ссылаетесь статически, исполняемый файл содержит полную копию каждой библиотеки, на которую вы ссылаетесь.
- при динамическом связывании исполняемый файл содержит только ссылки и перехватчики на связанные библиотеки, что представляет собой гораздо меньший объем кода.

Answer 4

Исполняемый файл должен содержать не только ваш код.

По крайней мере, он содержит некоторый код запуска, настройку среды и, при необходимости, загрузку любых внешних библиотек перед запуском программы.

Если вы статически связали библиотеку времени выполнения, она также будет включена в ваш исполняемый файл.В противном случае вы получите лишь небольшую заглушку, достаточно большую для перенаправления системных вызовов во внешнюю среду выполнения.

В зависимости от настроек компилятора он также может включать в себя много отладочной информации и других несущественных данных.Если оптимизация включена, это также может привести к увеличению размера кода.

Настоящий вопрос в том, почему это имеет значение?800 КБ по-прежнему легко помещается на дискете!По большей части это единоразовые затраты.это не значит, что если вы напишете вдвое больше кода, он займет 1600 КБ.Скорее всего, это займет 810 КБ или что-то в этом роде.

Не беспокойтесь о единовременных затратах на запуск.

Answer 5

Используйте флаги -O3 и -s для создания наиболее оптимизированного двоичного файла.Также посмотрите это связь для получения дополнительной информации.

Если вы создаете программу для Windows, рассмотрите возможность использования компилятора Microsoft.Он всегда создает наименьший двоичный файл на этой платформе.

Answer 6

Размер обычно приводит к тому, что в ваше приложение подключаются статические библиотеки.

Вы можете уменьшить размер скомпилированного двоичного файла, скомпилировав его в версии RELEASE с оптимизацией до размера двоичного файла.

Другим источником размера исполняемого файла являются библиотеки.Вы сказали, что не используете внешние библиотеки, за исключением STD, поэтому я считаю, что вы включаете среду выполнения C в свой исполняемый файл, то есть компонуете статически.поэтому проверьте динамическое связывание.

ИМХО, вам не стоит об этом беспокоиться, но если вы действительно параноик, проверьте это: Самый маленький x86 ELF Hello World

Answer 7

Используйте Visual C ++ 6.0. Он поддерживается Windows 95 для Windows 7.и может быть скомпилирован как платформы x86, но только для Windows.поэтому, если вы являетесь пользователем Windows, просто придерживайтесь компиляторов Windows, отличных от GCC, что на самом деле является лучшим. Большинство людей, которые говорят, что Visual C++ - это лучший вариант, потому что они являются анти-Microsofters.Также не забудьте использовать «Visual C++ 6.0», если вы используете более новую версию, вероятно, вы не сможете запускать файлы в Windows 95.Я проверил все эти вещи, поэтому я сказал.GCC создает самые большие двоичные файлы, а Visual C++ - нет. Компилятор Intel может использовать его для экономии более 30% места, но для этого требуется процессор Intel, если производительность не будет ужасной.Еще одна вещь, которую вам нужно помнить, это когда вы используете шаблоны, хотя вы видите небольшие линии, когда вы компилируете эти функции, будут расширены, поэтому результат - сделать более крупные двоичные файлы.Если вам нужны меньшие двоичные файлы, я предлагаю перейти к C, потому что C на самом деле широко используется, но не настройка C является простым в использовании, чем C ++, это имеет смысл, тогда C ++ Пример

cout << "Привет, мир" << endl;printf("%s","Привет, мир");

второй говорит, что поле печати %s означает, что вы вводите строку, так что это легко.:П