Проблема в следующем.

Используем GCC 3.3.6. + стандартный makе.
Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
вы ее решили.

Спасибо

Жалко нет оценки "Гм..."

Здравствуйте, Nia, Вы писали:

Nia>Проблема в следующем.

Nia>Используем GCC 3.3.6. + стандартный makе.
Nia>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Nia>Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
Nia>вы ее решили.

Да, есть такая проблема на юниксах...

Для начала для тех, кто отвечал "Гм.. и Хм..." : чтобы достичь такого размера бинарника, исходников надо примерно метров сто. В релизе бинарник у нас занимал метров 70, а вот в Debug... Беда, по-видимому, в том, что отладочную информацию Gcc кладет в сам бинарник, а не в отдельный файл (MSVC кладет в .pdb).

Как мы решали эту проблему: в Debug компилировали только те модули, которые надо было отлаживать. Остальные — без отладочной информации. Бинарник был метров под 150 и жить, в принципе, было можно.

Более кардинальный вариант — если система 64-битная, то компилировать под 64-битную платформу, и соответственно собирать 64-битный ELF. Но здесь уже нужно менять исходники (int и, кажется, long для 64 битов становятся синонимами и перегруженные функции выдают ошибки).

Здравствуйте, Nia, Вы писали:

Nia>Используем GCC 3.3.6. + стандартный makе.
Nia>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Nia>Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
Nia>вы ее решили.
Слава Богу, не сталкивался с подобным, и не знаю, как помочь. Но один вопрос дико интересует — как дошли до жизни такой? Это же простите сколько мегабайт исходников компилится и сколько по времени это занимает? Как в такой ситуации просто вносить изменения — ведь статическая линковка таких объемов должна занимать массу времени! И вообще — КАК???

Аффтар, вазми яву !

Здравствуйте, Nia, Вы писали:

Nia>Проблема в следующем.
Nia>Используем GCC 3.3.6. + стандартный makе.
Nia>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Nia>Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
Nia>вы ее решили.

А в релизе он сколько?
А откуда получается 2 гига если не секрет?
Все что можно придумать — это влинковать в исполняемый модуль пару фильмов в mp4
в качестве ресурса для Диалога About

Здравствуйте, Kh_Oleg, Вы писали:

K_O>Более кардинальный вариант — если система 64-битная, то компилировать под 64-битную платформу, и соответственно собирать 64-битный ELF. Но здесь уже нужно менять исходники (int и, кажется, long для 64 битов становятся синонимами и перегруженные функции выдают ошибки).
int остаётся 32-битным, а long становится 64-битным. А синонимами они даже на 32-разрядной платформе не были.

Здравствуйте, Nia, Вы писали:

Nia>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).

А может это у вас адресное пространство процесса закончилось?

Здравствуйте, Nia, Вы писали:

Ni a>Проблема в следующем.

Nia>Используем GCC 3.3.6. + стандартный makе.
Nia>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Nia>Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
Nia>вы ее решили.

Nia>Спасибо

Чтобы сделать исполняемый файл больше 2ГБ надо иметь талант!
Вы наверное STL используете?
Ну, один путь Вам сказали — дебажную версию только той библиотеки, которую в данный момент отлаживаете.
А еще можно сделать так:

/********************************************/
// файл одна_из_подсистем.cpp
/********************************************/
# include <file1.cpp>
# include <file2.cpp>
# include <file3.cpp>
# include <file4.cpp>
# include <file5.cpp>

Обьем и время компиляции упадет в 5 раз. Засчет чего? За счет шаблонов и заголовочный файлов.
А вообще-то надо руки выпрямлять. Это-ж надо — 2 гигабайта!!!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Kh_Oleg, Вы писали:

K_O>>Более кардинальный вариант — если система 64-битная, то компилировать под 64-битную платформу, и соответственно собирать 64-битный ELF. Но здесь уже нужно менять исходники (int и, кажется, long для 64 битов становятся синонимами и перегруженные функции выдают ошибки).
А>int остаётся 32-битным, а long становится 64-битным. А синонимами они даже на 32-разрядной платформе не были.

Значит, это не int и long, а long и long long. Я уже точно не помню. Просто точно помню, что возникала проблема именно из-за того, что перегруженные функции перестали быть перегруженными.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Nia, Вы писали:

А>Ni a>Проблема в следующем.

Nia>>Используем GCC 3.3.6. + стандартный makе.
Nia>>Однако на данный момент продукт разросся настолько, что размер executable (в debug режиме) превышает 2 гб и ld просто отказывается линковать (линковка статическая).
Nia>>Пожалуйста, если кто сталкивался с такой проблемой, расскажите как
Nia>>вы ее решили.

Nia>>Спасибо

А>Чтобы сделать исполняемый файл больше 2ГБ надо иметь талант!
А>Вы наверное STL используете?
А>Ну, один путь Вам сказали — дебажную версию только той библиотеки, которую в данный момент отлаживаете.
А>А еще можно сделать так:

А>/********************************************/
А>// файл одна_из_подсистем.cpp
А>/********************************************/
А># include <file1.cpp>
А># include <file2.cpp>
А># include <file3.cpp>
А># include <file4.cpp>
А># include <file5.cpp>

А>Обьем и время компиляции упадет в 5 раз. Засчет чего? За счет шаблонов и заголовочный файлов.
А>А вообще-то надо руки выпрямлять. Это-ж надо — 2 гигабайта!!!


Спасибо, обЪем 2 гб получается за счет OA (open access), которая спроектирована по принципу "используй этот header и получишь что тебе надо"

Спасибо за предоствленные варианты К сожалению пока ни одно решение не заработало.

Может попробовтаь линковать бинарник не из библиотек подсистемы, а сразу из object файлов, из которых состоят эти библиотеки?
Есть ли разница между этими методами линка?

Здравствуйте, Nia, Вы писали:

Nia>Спасибо за предоствленные варианты К сожалению пока ни одно решение не заработало.

Еще варианты:
— разместить отладочные код и данные в отдельные от остальных секции;
— вынести некоторые части проекта в динамические библиотеки и подргужать/выгружать их по мере необходимости.

Nia>Может попробовтаь линковать бинарник не из библиотек подсистемы, а сразу из object файлов, из которых состоят эти библиотеки?
Nia>Есть ли разница между этими методами линка?

Нет, разницы никакой не будет. Может быть даже хуже, если прилинкуете object-файл, который не используется.