В объектном файле слишком много разделов
Мы активно используем boost :: serialization и templates в целом. Кажется, все идет хорошо.
Кроме того, мы нанесли удар по нашим assemblyм 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
- Microsoft Visual Studio: opendir () и readdir (), как?
- getopt.h: Компиляция C-кода Linux в Windows
- Утверждение не выполнено (size.width> 0 && size.height> 0)
- Ориентация .NET Framework 4.5 с помощью Visual Studio 2010
- Использовать Visual Studio 2012 и компилироваться со старым набором инструментов платформы?
В нем это указывает на то, что другой человек сильно ударил по одной и той же ловушке. Он указывал на опцию опции Visual Studio /bigobj которая, как представляется, делает то, что нам нужно. Однако мы не можем перейти к Visual Studio.
Одно из предложений заключалось в добавлении –hash-size в опции ассемблера. Это не помогло.
Если я не ошибаюсь, проблема заключается в том, что в объектных файлах есть ограничение на 2 ^ 16 записей. На самом деле, согласно сообщению об ошибке, я бы рискнул, что это подписанные 2 ^ 16 записей, но это арахис. Опция /bigobj для Visual Studio изменила бы это на 2 ^ 32. Результат списка рассылки не знал об эквивалентной опции для gcc. Дальнейшие результаты Google, похоже, не имеют отношения к этому.
На этом этапе нам придется реорганизовать наш код (ugh), чтобы обойти это ограничение. Но я по-прежнему обеспокоен тем, что с тяжелыми шаблонами мы снова и снова сталкиваемся с проблемой (мы уже сталкиваемся с ней с тремя исходными файлами).
Поэтому мой вопрос: есть ли gcc эквивалент опции Microsoft /bigobj ? Есть третий вариант, который я еще не нашел?
- Нет IntelliSense для C ++ / CLI в Visual Studio 2010?
- Команда для разваливания всех разделов кода?
- Скорость шифрования всего TrueCrypt
- Как вы собираете визуальный проект студии c ++ для выпуска?
- Как подключиться к LocalDB в Visual Studio Server Explorer?
- Почему иногда Windows не может убить процесс?
- Не удается запустить веб-приложение ASP.NET MVC 2 на IIS 7.5
- Изменения в базе данных Access не сохраняются при запуске приложения в Visual Studio
Решение заключается в добавлении опции -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 с до 2 31 секциями, что «должно быть достаточно для кого-то». Тем не менее, формат munged формально недокументирован, и я не вижу никакой неофициальной документации (сообщения в блогах или что-то-вы) по этому вопросу, поэтому пока кто-то с копией MSVC не сможет написать спецификацию для /bigobj , это не имеет большого шанса попасть в инструменты GNU.
ИМХО, если вы пытаетесь сделать сборку 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, с каждым шагом он будет создавать меньший объектный файл, он может решить проблему, это было в моем случае. Да, для отладочных compilationов это может быть нежелательно, вы можете попробовать -Og также