gcc 4.3 vs gcc 4.7

Флаги?

А сколько clang 3.2 генерит?

флаги по умолчанию дополнительных не задавал.

посмотреть в makefile?

эм, не понял.

это скомпилировать надо или это тест какой то

флаги по умолчанию дополнительных не задавал.

Тогда скорее всего -O2, то есть gcc не обязан минимизировать размер. Плюс он мог не убрать неиспользуемые функции в более новой версии, мало ли. Плюс отладочная информация могла затесаться. Если эти факторы устранить, то обновлённые результаты могут получиться равными.

Вот сводочка по флагам

# оптимизация размера кода, (можно добавить -flto вдовесок,
# однако LTO может и поломать программу)
-Os
# опции линковщика
--strip-all --gc-sections
# помогает удалить неиспользуемые функции (вряд ли поможет в busybox)
-fvisibility=hidden -fvisibility-inlines-hidden

Ах да, чтобы быстро определить наиболее вероятное, можно просто пострипать бинарники утилитой strip: 'strip FILENAME'

это компилятор, к.о

спасибо вот про lto как раз вспомнилось что binutils с поддержкой этого собирались

strip вроде автоматом делается, проверю.

--gc-sections

Без -fdata-sections -ffunction-sections скорее всего бесполезен

А .config точно тот же?

clang 3.2 генерит меньше по размеру бинарник.

Когда как. Бывает меньше, бывает и сильно больше.

1. Попробуй добавить в CFLAGS -fno-asynchronous-unwind-tables,

2. Версии glibc одинаковые? У меня с 2.16 busybox получался гораздо большим, чем с 2.13. Оказалось, что для строковых функций в 2.16 (или одной из более ранних) появились SSE/SSE2/SSE3/SSSE3/SSE4/SSE4.2/etc. аналоги и при статической компоновке все эти аналоги помещаются в бизибокс, существенно увеличивая его размер. После этого я перешёл на uClibc для сборки бизибокса.

man gcc

man strip

man хоть-что-нибудь

После этого я перешёл на uClibc для сборки бизибокса.

MUSL достаточно

Пострипать не забудь. Возможно просто больше дебажной инфы или её формат по-умолчанию изменился (типа stabs -> dwarf)

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

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

Например, более умный компилятор разворачивает циклы и делает выравнивание, в результате чего файл пухнет, но и возрастает скорость работы, а глупый компилятор собирает «как есть». Собственно, компилятор Visual Studio делает бинарники раза в 3 «худее», чем gcc.

как сказать busybox чтобы использовал uclibc а не gcc, пните в нужном направлении.

uclibc в системе есть.

Канпелять busybox придётся, братюнь.

спасибо кэп.

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

Странно но по сравнению с 4.3 при компиляции в 4.7 сыпятся предупреждения:

Доступ по указателю с приведением типа нарушает правила перекрытия объектов в памяти (-Wstrict-aliasing)

Не то чтобы напрягает, но как интерпретировать, незнаю

как сказать busybox чтобы использовал uclibc а не gcc, пните в нужном направлении.

Не знаю, как собрать с уже установленным в систему uClibc. Я ставлю во временный каталог ($PWD/PKG), т.к. линковка всё равно статическая и в реальной системе мне uClibc не нужен. Думаю, на реальной системе будет то же самое, но вместо $PWD/PKG потребуется добавлять в X*FLAGS /usr. CFLAGS/LDFLAGS - мои флаги, можно их оставить пустыми.

# из каталога с распакованным uClibc-0.9.33.2
make UCLIBC_EXTRA_CFLAGS="$CFLAGS $LDFLAGS" \
     V=2 RUNTIME_PREFIX=$PWD/PKG/ DEVEL_PREFIX=$PWD/PKG/ install
ln -s /usr/include/{linux,asm{,-generic}} $PWD/PKG/include

XCFLAGS=" -nostdinc -I$PWD/PKG/include -I`gcc -print-file-name=include` -I`gcc -print-file-name=include-fixed`"
XLDFLAGS=" -nostartfiles $PWD/PKG/lib/crt1.o -L$PWD/PKG/lib"

# из каталога с распакованным busybox-1.20.2
make CONFIG_EXTRA_CFLAGS="$CFLAGS$XCFLAGS" \
     CONFIG_EXTRA_LDFLAGS="$LDFLAGS$XLDFLAGS" \
     V=1 all

make CONFIG_EXTRA_CFLAGS="$CFLAGS$XCFLAGS" \
     CONFIG_EXTRA_LDFLAGS="$LDFLAGS$XLDFLAGS" \
     V=1 install

идет простой процесс отработки решения чтобы в будущем использовать при сборке других программ.

Кстати, -fno-asynchronous-unwind-tables пробовал добавлять? На gcc-4.6 эта опция размер бинарника (проверял в частности на sed) уменьшает на 10-20%, примерно до размеров того же приложения, собранного gcc-4.4.

нет не пробовал еще.

вобще busybox это просто наглядный показатель проблемы моей

Это наглядный пример того, что ты пропускаешь уроки

Это наглядный пример того, что ты пропускаешь уроки

вдоль

Исполняемый файл share/chromium/chrome:

Полученный GCC 4.6.3 — 80,5 МБ (84 389 192 Bytes)

Полученный LLVM/Clang 3.2 — 68,3 МБ (71 609 584 Bytes)

Разница есть? Существенная.

Размеры архивов:

chromium-24.0.1312.57_1.tbz (GCC 4.6.3) — 38,8 МБ (40 673 049 Bytes)

chromium-24.0.1312.57_1.tbz (LLVM/Clang 3.2) — 33,4 МБ (35 040 866 Bytes)

chromium

lto небось включено.

P.S.

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

LTO отключено.

тогда не знаю.
Повторюсь - у меня под гентой результаты скакали как кролики в брачный период. Разница в размере до 2х раз доходила, причем как в ту, так и в другую сторону.

Исполняемый файл share/chromium/chrome:

С какими флагами собиралось (для каждого компилятора)?

by default — http://svnweb.freebsd.org/ports/head/www/chromium/Makefile?revision=311648&am...

by default

Прошу прощения, но я не нашёл там ничего похожего на -O2 и т.п. Не исключаю, что при сборке gcc был включён какой-нибудь -finline-all-functions -funroll-all-loops -O3, тогда как при сборке clang использовался аналог традиционного -O2 (или даже -Os).

Какие конкретно флаги используются «by default»?

Не могу ничего по этому поводу сказать.