В объектном файле слишком много разделов

Question

Мы активно используем 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 эквивалент опции /bigobj от Microsoft? Есть третий вариант, который я еще не нашел?

Answer 1

Ошибка "%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 с до 2 разделов, которые «должно быть достаточно для всех.» Тем не менее, формат munged формально недокументирован, и я не вижу никакой неофициальной документации (сообщений в блогах или того, что у вас есть) по этому вопросу, поэтому пока кто-то с копией MSVC не сможет написать спецификацию для /bigobj, это не так У меня много шансов попасть в инструменты GNU.

IMHO, если вы пытаетесь сделать сборку Windows, вам нужно просто укусить пулю и использовать MSVC. Никто кроме Microsoft не имеет особого желания тратить время на борьбу с форматом PE/COFF.

Answer 2

Я столкнулся с той же проблемой, когда я скомпилировал библиотеку Poco с помощью MinGW-w64, оказалось, что объект отладки был огромным для одного файла реализации.

Как вы, mentioned before, вы можете разделить файлы cpp, и это будет работать, но когда вы сталкиваетесь с чьим-то исходным кодом, вы не можете этого сделать, не нарушая что-то.

В качестве решения вы можете включить оптимизацию компилятора: начиная с -O1 до -O3, с каждым шагом он будет создавать меньший объектный файл, он может решить проблему, это было в моем случае. Да, для отладки строит это может быть нежелательным, you can try -Og а

Answer 3

Я нашел некоторые обновления в этом вопросе, кажется, должны быть зафиксированы в новом Binutils для 64 окон, см https://sourceware.org/ml/binutils/2014-03/msg00114.html и http://sourceforge.net/p/mingw-w64/bugs/341/. Однако я не тестировал его, поскольку это исправление не относится к 32-битным версиям, которые мне нужны.

Answer 4

Решение состоит в том, чтобы добавить опцию -Wa,-mbig-obj, если ваша версия GCC поддерживает эту опцию. Вероятно, вам это нужно только на этапе компиляции, а не на этапе компоновщика.

Если ваш компилятор не поддерживает этот параметр, вы должны изучить использование mingw-w64 и MSYS2.