попридержать gcc

ulimit -m
ulimit -v
для ограничения памяти,
ключики для gcc:
http://www.linux.org.ru/view-message.jsp?msgid=3833395

добавить -finline-limit=30 с CFLAGS

если есть -pipe - нужно убрать

-param ggc-min-expand=0 --param ggc-min-heapsize=8192

еще вот такие флажки можно попробовать для ограничения heap используемного gcc

> Есть .c файл размером в 30 Mb, который хранит бинарные данные, конвертированные в Си массив

не уверен что сие есть гут. может быть вынести данные в отдельный файл и оттуда читать ?

это пока невозможно по техническим причинам

ничего из этого не помогает. Флаги gcc не помогают вообще, с установленным ulimit gcc просто вылетает c «virtual memory exhausted: Невозможно выделить память».

Есть .c файл размером в 30 Mb, который хранит бинарные данные, конвертированные в Си массив, типа

static const char BLB[] = { 0x7f, 0x45, ... };

Зачем было конвертировать их в код на C?

ld -r -b binary -o data.o data.bin

интересная мысль, попробую переделать

можно разнести препроцессинг и компиляцию
gcc -E -o main.i main.c
gcc main.i -o main.o

компилировать можно и на другой машине где много памяти,
если файлик не конфиденциальный, может выложите main.i после препроцессора ?

Можно попробовать tcc.

препроцессинг тут ничтожно мал, это же не С++.

если файлик не конфиденциальный, может выложите main.i после препроцессора ?

там смотреть не на что - несколько системных include-ов и 30Mb hex-ов.

Никогда не делать так с бинарными данными, а использовать objcopy (man objcopy).

а на хостинге всю оперативу и своп

добавить своп файл не?

спасибо, помогло, решил через objcopy.

>несколько системных include-ов и 30Mb hex-ов.
может лучше отделить «30Mb hex-ов.» в отдельный файл без «системных include-ов»?

А насколько вообще разумно хранить такой блоб в коде? Скорости работы это не прибавит нифига.

AFAIK, это проблема парсера gcc. Рекурсивного. На каждую запятую - по уровню вложенности. Не лечится.

В качестве пруфа - линк на очень-очень похожу багу. Дальше искать лень. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087

Можно посмотреть, сколько памяти при компиляции этого файла будет жрать gcc 4.0 . Нынешний парсер они вроде бы вкутили в gcc 4.1