问题
When I try to buld a large complex example (modified to be more complex in terms of templates instantiations) from the boost spirit Qi compiler_tutorial I get the following error message:
debug\expression.o:-1: error: section .debug_frame$_ZNK5boost5proto3if_INS0_6detail7has_tagINS0_6tagns_3tag7greaterEEENS0_12reverse_foldINS0_1_ENS0_6_stateENS2_18reverse_fold_tree_IS6_NS_6spirit6detail18make_binary_helperINSC_13meta_compilerINSC_2qi6domainEE12meta_grammarEEEEEEESK_E4implIRNSG_4ruleINSC_3lex7lexertl8iteratorINSR_7functorINSR_14position_tokenIN9__gnu_cxx17__normal_iteratorIPKcSsEENS_3mpl6vectorISsN4mpl_2naES13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EENS12_5bool_ILb0EEEyEENSR_6detail4dataESZ_NS15_ILb1EEES16_EEEEFSt4listIN7client3ast10expressionIdEESaIS1H_EEvENSC_11unused_typeES1L_S1L_EENS_6fusion4consINSG_12literal_charINSC_13char_encoding8standardELb1ELb0EEENS1O_4nil_EEERS1L_EclES1N_RKS1V_S1W_: string table overflow at offset 10000433
The command line:
c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/cc1plus.exe -quiet -v -I c:/libs/boost/include -I ../src/compiler -I c:/libs/boost/include -I . -I c:/libs/Qt-static/mkspecs/win32-g++-x64-4.7.2-corei7-avx-corei7-avx -iprefix c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.2/ -D_REENTRANT -U_REENTRANT -D BOOST_THREAD_POSIX -D BOOST_THREAD_USE_LIB -D UNICODE -D QT_LARGEFILE_SUPPORT -D _DEBUG=1 -D DEBUG=1 -D BOOST_SPIRIT_QI_DEBUG=1 -D BOOST_SPIRIT_NO_PREDEFINED_TERMINALS=1 ../src/compiler/expression.cpp -quiet -dumpbase expression.cpp -m64 -march=corei7-avx -mtune=corei7-avx -mtls-dialect=gnu2 -auxbase-strip debug/expression.o -g -O0 -Wall -Wextra -std=gnu++11 -version -fsignaling-nans -fno-math-errno -frtti -fexceptions -o - |
The platform: mingw-builds (x64-4.7.2-release-posix-sjlj-rev5.7z) for x64 host and target (-m64) (conform to gcc 4.7.2) on x64 Windows 7 HB with 8GB physical memory.
It looks like it is because there is not enough memory.
What should I do to avoid this problem? I am sure that there is not recursive templates here.
回答1:
I had a similar problem and found a solution. I use a lot of boost template classes from the Boost.Spirit2 parser.
I use the MingW64 cross-compiler on openSuse 12.2 (gcc 4.7.2) MingW32 has no trouble compiling the same files, neither in release, nor in debug mode.
command:
/usr/bin/x86_64-w64-mingw32-g++ -c -fpermissive -fexceptions -Wall -Wextra -Wno-long-long -Wno-unknown-pragmas -mthreads -Wall -frtti -finline-functions -o file.o file.cpp
output:
section .pdata$_ZN5boost6fusion6detail10linear_anyINS0_13cons_iteratorIKNS0_4consINS_6spirit2qi6kleeneINS6_10char_classINS5_3tag9char_codeINS9_5spaceENS5_13char_encoding8standardEEEEEEENS4_INS6_11alternativeINS4_INS6_6actionINSI_INSI_INS6_8sequenceINS4_INSI_INS6_14literal_stringIRA11_KcLb1EEENS_7phoenix5actorINSP_9compositeINSP_6detail13function_evalILi2EEENS0_6vectorINSP_5valueINSP_3stl9push_backEEENSP_9referenceISsEENSW_IcEENS0_5void_ES13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EEEEEEEENS4_INS6_16lexeme_directiveINS7_INSI_INS6_10differenceINS8_INSA_INS9_5char_ESD_EEEENS6_10eol_parserEEENSQ_INSR_ISU_NSV_ISZ_S11_NS5_8argumentILi0EEES13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_Ssos-nightly@suse-x86-64:~/mnt/joseph/suse/build__mingw64__individual__next__debug/src/sos_import> _SF_EEEENS4_ISG_NS0_3nilEEEEEEEEEEENS4_INS6_4plusINSI_INS6_9referenceIKNS6_4ruleIN9__gnu_cxx17__normal_iteratorIPSL_SsEEFN7dynardo9structure11SimplexDataEvENS_5proto7exprns_4exprINS2A_6tagns_3tag8terminalENS2A_7argsns_4termINSA_INS9_5blankESD_EEEELl0EEENS5_11unused_typeES2M_EEEENSQ_INSR_ISU_NSV_INSW_INSS_19member_function_ptrILi1EvM11My_PushbackINS27_20SimplexDataContainerEEFvRKS28_EEEEENSW_IPS2T_EES1G_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EEEEEEEEEES1T_EEEEEEEEEEEENSQ_INSR_ISU_NSV_INSW_INSX_6insertEEENS10_ISt3mapISsS2S_St4lessISsESaISt4pairIKSsS2S_EEEEENS10_IS3I_ISsS2S_EEES13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EEEEEEEENSQ_INSR_INST_ILi1EEENSV_INSW_INSX_5clearEEES11_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EEEEEEEENSQ_INSR_IS3U_NSV_IS3W_NS10_IS2S_EES13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_S13_EEEEEEEENS4_INSI_INSI_INSI_INSJ_INS4_INSK_IRA9_SL_Lb1EEENS4_IS1S_NS4_ISG_S37_EEEEEEEES3S_EES3Z_EES44_EENS4_INSJ_IS1V_EES1T_EEEEEEEES1T_EEEEEENS3_IKS1T_EENS6_6detail13fail_functionIS25_KS2M_NS8_IS2J_EEEEEEbRKT_RKT0_RT1_N4mpl_5bool_ILb0EEE: string table overflow at offset 10002537 /tmp/ccMd36nu.s: Assembler messages: /tmp/ccMd36nu.s: Fatal error: can't close debug/osl_lsdyna_k_parser.o: File too big
It seems that the missing optimization option is the problem. Adding -O1 or -O2
/usr/bin/x86_64-w64-mingw32-g++ -c -fpermissive -fexceptions -Wall -Wextra -Wno-long-long -Wno-unknown-pragmas -mthreads -Wall -frtti -O1 -g -o file.o file.cpp
fixes the problem for me and even allows debug options (-g)!
回答2:
I found the one answer to this question unsatisfying, but after further research, it really does appear that running gcc with a higher optimization level is how to get around this problem. I thought I'd share what I learned.
This problem is specific to writing binaries in the PE/COFF format, which is what Windows uses. Grepping the source of binutils, I found this code snippet/comment in bfd's coff backend code:
/* An inherent limitation of the /nnnnnnn notation used to indicate
the offset of the long name in the string table is that we
cannot address entries beyone the ten million byte boundary. */
if (string_size >= 10000000)
{
bfd_set_error (bfd_error_file_too_big);
(*_bfd_error_handler)
(_("%B: section %s: string table overflow at offset %ld"),
abfd, current->name, string_size);
return FALSE;
}
The string table in the binary looks like it can be a maximum of 10 million bytes in PE/COFF. I believe that the only thing that constrains it is that the format for a section table entry only specifies 8 bytes for a section name. If a name is longer than that, it can specify an offset into the string table. The number must be represented by ASCII in UTF-8 encoded string and begin with a forward slash. That only gives you seven base-10 digits, hence the 10,000,000 limit. I found this in Section 13 of Microsoft's PE/COFF specification revision 8.1.
You can't really budge the binary format, so the only workaround that I know of is to get gcc to make a smaller string table. -O2 did the trick for me.
来源：https://stackoverflow.com/questions/14125007/gcc-string-table-overflow-error-during-compilation