如何修复编译>2 GB代码时的GCC编译错误？

我有大量的函数，总计约2.8 GB的目标代码(不幸的是，科学计算…)

当我尝试链接它们时，我会得到(预期的)relocation truncated to fit: R_X86_64_32S错误，我希望通过指定编译器标志-mcmodel=medium来避免这些错误。除了我可以控制的库之外，所有链接的库都使用-fpic标志进行编译。

尽管如此，错误仍然存在，我认为我链接到的一些库没有使用PIC编译。

错误如下：

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x12): relocation truncated to fit: R_X86_64_32S against symbol `__libc_csu_fini'     defined in .text section in /usr/lib64/libc_nonshared.a(elf-init.oS)
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x19): relocation truncated to fit: R_X86_64_32S against symbol `__libc_csu_init'    defined in .text section in /usr/lib64/libc_nonshared.a(elf-init.oS)
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o: In function    `call_gmon_start':
(.text+0x7): relocation truncated to fit: R_X86_64_GOTPCREL against undefined symbol      `__gmon_start__'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0xb): relocation truncated to fit: R_X86_64_PC32 against `.bss' 
crtstuff.c:(.text+0x13): relocation truncated to fit: R_X86_64_32 against symbol `__DTOR_END__' defined in .dtors section in /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o
crtstuff.c:(.text+0x19): relocation truncated to fit: R_X86_64_32S against `.dtors'
crtstuff.c:(.text+0x28): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x38): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x3f): relocation truncated to fit: R_X86_64_32S against `.dtors'
crtstuff.c:(.text+0x46): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x51): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
make: *** [testsme] Error 1

我链接的系统库：

-lgfortran -lm -lrt -lpthread

有什么线索可以从哪里找到这个问题吗？

编辑：

首先，感谢大家的讨论。。。

为了澄清一点，我有数百个函数(每个函数在单独的对象文件中的大小约为1MB)，如下所示：

double func1(std::tr1::unordered_map<int, double> & csc, 
std::vector<EvaluationNode::Ptr> & ti, 
ProcessVars & s)
{
double sum, prefactor, expr;
prefactor = +s.ds8*s.ds10*ti[0]->value();
expr =       ( - 5/243.*(s.x14*s.x15*csc[49300] + 9/10.*s.x14*s.x15*csc[49301] +
1/10.*s.x14*s.x15*csc[49302] - 3/5.*s.x14*s.x15*csc[49303] -
27/10.*s.x14*s.x15*csc[49304] + 12/5.*s.x14*s.x15*csc[49305] -
3/10.*s.x14*s.x15*csc[49306] - 4/5.*s.x14*s.x15*csc[49307] +
21/10.*s.x14*s.x15*csc[49308] + 1/10.*s.x14*s.x15*csc[49309] -
s.x14*s.x15*csc[51370] - 9/10.*s.x14*s.x15*csc[51371] -
1/10.*s.x14*s.x15*csc[51372] + 3/5.*s.x14*s.x15*csc[51373] +
27/10.*s.x14*s.x15*csc[51374] - 12/5.*s.x14*s.x15*csc[51375] +
3/10.*s.x14*s.x15*csc[51376] + 4/5.*s.x14*s.x15*csc[51377] -
21/10.*s.x14*s.x15*csc[51378] - 1/10.*s.x14*s.x15*csc[51379] -
2*s.x14*s.x15*csc[55100] - 9/5.*s.x14*s.x15*csc[55101] -
1/5.*s.x14*s.x15*csc[55102] + 6/5.*s.x14*s.x15*csc[55103] +
27/5.*s.x14*s.x15*csc[55104] - 24/5.*s.x14*s.x15*csc[55105] +
3/5.*s.x14*s.x15*csc[55106] + 8/5.*s.x14*s.x15*csc[55107] -
21/5.*s.x14*s.x15*csc[55108] - 1/5.*s.x14*s.x15*csc[55109] -
2*s.x14*s.x15*csc[55170] - 9/5.*s.x14*s.x15*csc[55171] -
1/5.*s.x14*s.x15*csc[55172] + 6/5.*s.x14*s.x15*csc[55173] +
27/5.*s.x14*s.x15*csc[55174] - 24/5.*s.x14*s.x15*csc[55175] +
// ...
;
sum += prefactor*expr;
// ...
return sum;
}

对象s相对较小并且保持所需的常数x14、x15、…、。。。，ds0。。。，而CCD_ 5只是从外部库返回一个double。如您所见，csc[]是一个预先计算的值映射，它也在以下形式的单独对象文件(同样是数百个，每个文件的大小约为1MB)中进行评估：

void cscs132(std::tr1::unordered_map<int,double> & csc, ProcessVars & s)
{
{
double csc19295 =       + s.ds0*s.ds1*s.ds2 * ( -
32*s.x12pow2*s.x15*s.x34*s.mbpow2*s.mWpowinv2 -
32*s.x12pow2*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
32*s.x12pow2*s.x15*s.x35*s.x45*s.mWpowinv2 -
32*s.x12pow2*s.x25*s.x34*s.mbpow2*s.mWpowinv2 -
32*s.x12pow2*s.x25*s.x35*s.mbpow2*s.mWpowinv2 -
32*s.x12pow2*s.x25*s.x35*s.x45*s.mWpowinv2 +
32*s.x12pow2*s.x34*s.mbpow4*s.mWpowinv2 +
32*s.x12pow2*s.x34*s.x35*s.mbpow2*s.mWpowinv2 +
32*s.x12pow2*s.x34*s.x45*s.mbpow2*s.mWpowinv2 +
32*s.x12pow2*s.x35*s.mbpow4*s.mWpowinv2 +
32*s.x12pow2*s.x35pow2*s.mbpow2*s.mWpowinv2 +
32*s.x12pow2*s.x35pow2*s.x45*s.mWpowinv2 +
64*s.x12pow2*s.x35*s.x45*s.mbpow2*s.mWpowinv2 +
32*s.x12pow2*s.x35*s.x45pow2*s.mWpowinv2 -
64*s.x12*s.p1p3*s.x15*s.mbpow4*s.mWpowinv2 +
64*s.x12*s.p1p3*s.x15pow2*s.mbpow2*s.mWpowinv2 +
96*s.x12*s.p1p3*s.x15*s.x25*s.mbpow2*s.mWpowinv2 -
64*s.x12*s.p1p3*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
64*s.x12*s.p1p3*s.x15*s.x45*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.p1p3*s.x25*s.mbpow4*s.mWpowinv2 +
32*s.x12*s.p1p3*s.x25pow2*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.p1p3*s.x25*s.x35*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.p1p3*s.x25*s.x45*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.p1p3*s.x45*s.mbpow2 +
64*s.x12*s.x14*s.x15pow2*s.x35*s.mWpowinv2 +
96*s.x12*s.x14*s.x15*s.x25*s.x35*s.mWpowinv2 +
32*s.x12*s.x14*s.x15*s.x34*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.x14*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
64*s.x12*s.x14*s.x15*s.x35pow2*s.mWpowinv2 -
32*s.x12*s.x14*s.x15*s.x35*s.x45*s.mWpowinv2 +
32*s.x12*s.x14*s.x25pow2*s.x35*s.mWpowinv2 +
32*s.x12*s.x14*s.x25*s.x34*s.mbpow2*s.mWpowinv2 -
32*s.x12*s.x14*s.x25*s.x35pow2*s.mWpowinv2 -
// ...

csc.insert(cscMap::value_type(192953, csc19295));
}
{
double csc19296 =      // ... ;
csc.insert(cscMap::value_type(192956, csc19296));
}
// ...
}

就这样，最后一步就是调用所有的func[i]并将结果相加。

关于这是一个相当特殊和不寻常的情况：是的，确实如此。这是人们在尝试为粒子物理学进行高精度计算时必须面对的问题。

第2版：

我还应该补充一点，x12、x13等并不是真正的常数。它们被设置为特定的值，所有这些函数都被运行并返回结果，然后选择一组新的x12、x13等来产生下一个值。这必须进行10⁵到10⁶次。。。

第3版：

感谢您迄今为止的建议和讨论。。。我会尝试以某种方式在代码生成时滚动循环，老实说，我不确定如何做到这一点，但这是最好的选择。

顺便说一句，我没有试图躲在"；这是科学计算，没有优化的方法
这只是这个代码的基础是从"；黑盒"；在我无法真正访问的地方，而且，整个事情用简单的例子做得很好，我主要对现实世界中的应用程序感到不知所措。。。

第4版：

因此，我已经通过简化计算机代数系统(Mathematica)中的表达式，将csc定义的代码大小减少了大约四分之一。我现在也看到了一些方法，可以通过在生成代码之前应用一些其他技巧将其减少一个数量级左右(这将使这部分减少到大约100MB)，我希望这个想法能奏效。

现在与您的答案相关：

我正在尝试在funcs中再次将循环回滚，在那里CAS不会有多大帮助，但我已经有了一些想法。例如，根据x12, x13,...等变量对表达式进行排序，使用Python解析csc，并生成将它们相互关联的表。那么我至少可以将这些部分生成为循环。由于这似乎是迄今为止最好的解决方案，我认为这是最好的答案。

不过，我也要赞扬VJo。GCC 4.6确实能更好地运行，生成更小的代码，速度更快。使用大模型可以按原样处理代码。所以从技术上讲，这是正确的答案，但改变整个概念是一个更好的方法。

感谢大家的建议和帮助。如果有人感兴趣，我会在准备好后尽快发布最终结果。

备注：

只是对其他一些答案的一些评论：我试图运行的代码并不是源于简单函数/算法的扩展和愚蠢的不必要的展开。实际情况是，我们从非常复杂的数学对象开始，将它们转换为数字可计算形式会生成这些表达式。问题实际上在于潜在的物理理论。众所周知，中间表达式的复杂性是按因子缩放的，但当将所有这些东西组合成物理上可测量的东西时——一种可观察的东西——它只能归结为构成表达式基础的少数非常小的函数。(在这方面，广义且仅可用的被称为"微扰理论"的ansatz肯定存在"错误"。)我们试图将这种ansatz提升到另一个层次，这在分析上不再可行，并且所需函数的基础尚不清楚。所以我们试着像这样暴力。这不是最好的方法，但希望最终能帮助我们理解手头的物理。。。

上次编辑：

多亏了你的所有建议，我使用Mathematica和func的代码生成器的修改，在一定程度上减少了代码大小：)

我用Mathematica简化了csc函数，使其减少到92MB。这是不可约的部分。第一次尝试花了很长时间，但经过一些优化，现在在单个CPU上只需10分钟即可完成。

对funcs的影响是显著的：它们的整个代码大小降到了大约9 MB，因此代码现在的总量在100 MB的范围内。现在，启用优化是有意义的，并且执行速度相当快。

再次感谢大家的建议，我学到了很多。