Мы активно используем boost:: serialization и templates в целом. Кажется, все идет хорошо.
Кроме того, мы нанесли удар по нашим сборкам Windows. Кажется, что проблемы в объектных файлах слишком велики. Мы используем MinGW/Msys с g++ 4.7.0.
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/as.exe: CMakeFiles/source.dir/sourcecode.cpp.obj: too many sections (33396)
C:\Users\username\AppData\Local\Temp\ccnAocvD.s: Assembler messages:
C:\Users\username\AppData\Local\Temp\ccnAocvD.s: Fatal error: can't write CMakeFiles/source.dir/sourcecode.cpp.obj: File too big
Мастер google открыл это заархивированное сообщение, http://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bsc5mkLvj%3DW9w2%3DsY%3Dc_N%3DEwnsQuPDEX%3DiBcbsbxS3CuE_5Bg%40mail.gmail.com&forum_name=mingw-users
В нем это указывает на то, что другой человек попал в ту же самую ловушку. Он указывал на опцию для опции Visual Studio /bigobj, которая, как представляется, делает то, что нам нужно. Однако мы не можем перейти в Visual Studio.
Одно из предложений заключалось в том, чтобы добавить --hash-size в опции ассемблера. Это не помогло.
Если я не ошибаюсь, проблема заключается в том, что в объектных файлах есть ограничение на 2 ^ 16 записей. Собственно, согласно сообщению об ошибке, я бы рискнул, что это подписанные 2 ^ 16 записей, но это арахис. Опция /bigobj для Visual Studio изменила бы это на 2 ^ 32. Результат списка рассылки не знал об эквивалентной опции для gcc. Дальнейшие результаты Google, похоже, не имеют отношения к этому.
На этом этапе нам придется реорганизовать наш код (ugh), чтобы обойти это ограничение. Но я все еще обеспокоен тем, что с тяжелыми шаблонами мы снова и снова сталкивались с проблемой (мы уже сталкивались с ней с тремя исходными файлами).
Итак, мой вопрос: существует ли gcc эквивалент опции Microsoft /bigobj? Есть ли еще третий вариант, который я еще не нашел?
Решение состоит в том, чтобы добавить опцию -Wa,-mbig-obj, если ваша версия GCC поддерживает эту опцию. Вероятно, вам это нужно только на этапе компиляции, а не на этапе компоновщика.
Если ваш компилятор не поддерживает этот параметр, вы должны изучить использование mingw-w64 и MSYS2.
Ошибка "%B: too many sections (%d)" происходит от функции coff_compute_section_file_positions(), расположенной в bfd/coffcode.h. Он создается, когда выходной файл .obj (в формате COFF) содержит более 32766 разделов. Невозможно избежать этой ошибки, по крайней мере, если вы не хотите использовать формат объекта Windows PE/COFF; Файлы COFF используют только два байта для "NumberOfSections" в заголовке файла.
Мне непонятно, почему as (сборщик GNU) закрывает количество секций на 32768-минус-2 вместо 65536-минус-1 (раздел 0 зарезервирован); но в любом случае этого может быть недостаточно, если вы сильно используете шаблоны, а ваш компилятор реализует шаблоны через разделы COMDAT.
Как вы уже заметили, передача /bigobj в компилятор Microsoft заставляет его выводить формат COFF с munged с двумя разделами 31 что "должно быть достаточно для кого-то". Тем не менее, формат munged формально недокументирован, и я не вижу никакой неофициальной документации (сообщения в блогах или что-то-вы) по этому вопросу, поэтому пока кто-то с копией MSVC не сможет написать спецификацию для /bigobj, у него мало шансов попасть в инструменты GNU.
IMHO, если вы пытаетесь создать сборку Windows, вам нужно просто укусить пулю и использовать MSVC. Никто кроме Microsoft не имеет особого отношения к тому, чтобы тратить время на борьбу с форматом PE/COFF.
Я нашел некоторые обновления в этом вопросе, кажется, исправлен в новых binutils для x64-окон, см. https://sourceware.org/ml/binutils/2014-03/msg00114.html и http://sourceforge.net/p/mingw-w64/bugs/341/. Однако я не тестировал его, поскольку это исправление не относится к 32-битным версиям, которые мне нужны.
У меня возникла та же проблема, когда я скомпилировал библиотеку Poco с помощью MinGW-w64, оказалось, что объект отладки был огромным для одного файла реализации.
Как вы уже упомянули , вы можете разделить файлы cpp, и это сработает, но когда вы сталкиваетесь с каким-то исходным кодом, вы не можете этого сделать, не нарушая что-то.
В качестве решения вы можете включить оптимизацию компилятора: начните с -O1 до -O3, с каждым шагом он будет создавать меньший объектный файл, он может решить проблему, как это было в моем случае. Да, для отладочных сборников это может быть нежелательно, вы также можете попробовать -Og