Le fichier objet comporte trop de sections
Nous utilisons beaucoup boost :: serialization et les modèles en général. Tout semble bien se passer.
Sauf que nous avons rencontré un problème sur nos versions Windows. Il semble que les fichiers objets soient trop volumineux. Nous utilisons MinGW/Msys avec 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 principal a révélé ce message archivé, http://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bsc5mkLvj%3DW9w2%3DsY%3Dc_N%3DEwnsQuPDEX%3DiBcbsbxS3CuE_5Bg%40mail.gmail=
Dans ce document, cela indique qu'une autre personne a à peu près le même problème. Il indiquait une option pour l'option /bigobj De Visual Studio qui semble faire ce dont nous aurions besoin. Cependant, nous ne pouvons pas passer à Visual Studio.
Une suggestion a été d'ajouter --hash-size aux options de l'assembleur. Cela n'a pas aidé.
Si je ne me trompe pas, le problème réside dans le fait que les fichiers objets ont une limite de 2 ^ 16 entrées. En fait, selon le message d'erreur, je me risquerais à penser qu'il s'agit d'un 2 ^ 16 entrées signées, mais c'est des arachides. L'option /bigobj Pour Visual Studio changerait cela en 2 ^ 32. Le résultat de la liste de diffusion ne connaissait pas d'option équivalente pour gcc. D'autres résultats Google ne semblent pas pertinents pour cela.
À ce stade, nous devrons refactoriser notre code (ugh) pour contourner cette limitation. Mais je reste préoccupé par le fait que, avec de nombreux modèles, nous pourrions rencontrer le problème encore et encore (nous l'avons déjà rencontré avec trois fichiers source).
Ma question est donc la suivante; existe-t-il un gcc équivalent à l'option /bigobj de Microsoft? Y a-t-il une troisième option que je ne trouve pas encore?
La solution consiste à ajouter l'option -Wa,-mbig-obj si votre version de GCC prend en charge cette option. Vous n'en avez probablement besoin que pendant l'étape de compilation, pas l'étape de l'éditeur de liens.
Si votre compilateur ne prend pas en charge cette option, vous devriez envisager d'utiliser mingw-w64 et MSYS2 .
L'erreur "%B: too many sections (%d)" provient de la fonction coff_compute_section_file_positions() située dans bfd/coffcode.h. Il est produit lorsque la sortie .obj Le fichier (au format COFF) contient plus de 32766 sections. Il n'y a aucun moyen d'éviter cette erreur, du moins pas si vous souhaitez utiliser le format d'objet PE/COFF de Windows; Les fichiers COFF utilisent uniquement deux octets pour "NumberOfSections" dans l'en-tête du fichier.
Je ne comprends pas pourquoi as (l'assembleur GNU) limite le nombre de sections à 32768-moins-2, au lieu de 65536-moins-1 (la section 0 est réservée ); mais de toute façon, cela pourrait ne pas être suffisant si vous faites un usage intensif des modèles et votre compilateur implémente les modèles via les sections COMDAT.
Comme vous l'avez déjà remarqué, en passant /bigobj au compilateur de Microsoft le fait sortir un format COFF munged avec jusqu'à 231 des sections qui "devraient être suffisantes pour tout le monde". Cependant, le format munged est formellement non documenté, et je ne vois aucune documentation informelle (articles de blog ou ce que vous avez) sur le sujet, donc jusqu'à ce que quelqu'un avec une copie de MSVC puisse rédiger une spécification pour /bigobj, il n'a pas beaucoup de chance d'entrer dans les outils GNU.
À mon humble avis, si vous essayez de créer une version Windows, vous devez simplement mordre la balle et utiliser MSVC. Personne à part Microsoft n'est particulièrement motivé à perdre du temps à lutter avec le format PE/COFF.
J'ai rencontré le même problème lorsque j'ai compilé la bibliothèque Poco avec MinGW-w64, il s'est avéré que l'objet de débogage était énorme pour un fichier d'implémentation.
Comme vous mentionné précédemment vous pouvez diviser les fichiers cpp et cela fonctionnera, mais lorsque vous faites face au code source de quelqu'un, vous ne pouvez pas le faire sans casser quelque chose.
Comme solution, vous pouvez activer les optimisations du compilateur: commencez par -O1 jusqu'à -O3, à chaque étape, il créera un fichier objet plus petit, cela peut résoudre le problème, comme dans mon cas. Oui, pour les versions de débogage, cela peut être indésirable, vous pouvez également essayer -Og
J'ai trouvé quelques mises à jour à ce sujet, il semble être corrigé dans de nouveaux binutils pour les fenêtres x64, voir https://sourceware.org/ml/binutils/2014-03/msg00114.html et - http://sourceforge.net/p/mingw-w64/bugs/341/ . Cependant, je ne l'ai pas testé car ce correctif ne s'applique pas aux versions 32 bits dont j'ai besoin.