在某些情况下,是否有任何令人信服的性能原因选择静态链接而不是动态链接？我已经听过或读过以下内容,但我对这个问题的了解不足以保证它的真实性.
1)静态链接和动态链接之间的运行时性能差异通常可以忽略不计.
2)(1)如果使用使用配置文件数据优化程序热路径的配置文件编译器,则不成立,因为使用静态链接,编译器可以优化代码和库代码.通过动态链接,您的代码可以进行优化.如果大部分时间都花在运行库代码上,那么这可能会产生很大的不同.否则,(1)仍然适用.
#include <iostream>
#include <map>
#include <thread>
#define SIZE 1024
#define AMOUNT 100000
#define THREADS 4
class A
{
private:
char a[SIZE];
};
void test()
{
std::cout << "test start\n";
std::map<int, A*> container;
for(int i=0; i<AMOUNT; i++)
{
A* a = new A();
std::pair<int, A*>p = std::make_pair(i, a);
container.insert(p);
}
std::cout << "test release\n";
for(int i=0; i<AMOUNT; i++)
{
auto iter = container.find(i);
delete iter->second;
container.erase(iter);
}
std::cout << "test end\n";
}
int main()
{
std::thread ts[THREADS];
for(int i=0; i<THREADS; i++) …我正在尝试制作尽可能便携的可执行文件.删除一些依赖项后,我在另一个系统上运行二进制文件时遇到以下情况:
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.15' not found (required by foob)
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by foob)
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by foob)
我更喜欢我的二进制文件不要求用户升级他们的libc版本,所以我也想删除这个依赖项.
生成上述二进制文件的链接器标志已包含在内-static-libgcc -static-libstdc++.为什么二进制文件仍然需要共享的libc.so.6？
我也尝试添加-static标志,但是当我尝试运行该二进制文件时,结果非常奇怪:
$ ls -l foob
-rwxr-xr-x 1 claudiu claudiu 13278191 Oct 10 13:03 foob
$ ./foob
bash: ./foob: No such file or directory
该怎么办？
编辑:
$ file foob
foob: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), …在Linux下使用g ++确定最佳静态链接顺序是否有任何不错的工具？我熟悉一般问题,包括(如果需要)使用重复引用单个库或--start-group和--end-group来解决循环依赖关系,但我想要的是,如果可能的话,是一个工具,将采取一堆.a文件并为他们吐出一个良好的静态链接顺序,必要时重复库,同时将重复保持在最低限度.
背景:我正在开发一个包含大约800K行继承c ++代码的项目,并尝试将其重构为更小,更易于管理的块.一些现有的文件是巨大的单块 - 今天我一直在与一个34K行.h文件搏斗,它定义了113个类和结构.许多类几乎完全是在.h文件中内联定义的.当我将其拆分为更小的块,并将一些实现代码迁移到.cpp文件时,Linux上所需的链接顺序不断变化.这可能是因为包含.h文件的每个库都用于编译自己所需的任何类的实现,现在他们必须链接到单个库文件中的公共实现.长期我们可能会将一些类重新组织到不同的库中,并打破一些依赖链,但是现在依赖性非常混乱,我正在尝试最小化对可能改变行为的代码的扰动.我不希望每次更改时都必须手动确定正确的链接顺序.建议？