gcc - 带有未定义符号的静态库？

Question

我正在尝试使用静态库构建项​​目,以便即使未安装库也可以使用二进制文件.但是,当我尝试这样做时,我收到很多关于未定义符号的错误.

看看这个库,我看到它有很多未定义的符号,即使它是一个.a静态库:

nm - u /usr/local/lib/libthis.a
....
U EVP_DigestFinal_ex
U EVP_DigestInit_ex
U EVP_DigestUpdate
U EVP_MD_CTX_cleanup
U EVP_MD_CTX_init

那些似乎是来自openssl; 其他人似乎来自libbzip2; 等等

问题:1.为什么static(.a)lib依赖于非静态编译的共享对象(例如libopenssl)？2.我该如何解决这个问题？尝试手动添加-lssl似乎不起作用.如何编译二进制文件而不具有外部依赖性？

Answer 1

为什么静态(.a)lib依赖于非静态编译的共享对象(例如libopenssl)？

几乎每个可以构建的静态库都有未解析的符号,例如

int my_open_for_read(const char *filename)
{
  return open(filename, O_RDONLY);  // unresolved reference to open
}

正如Marc Glisse指出的那样,这是一个普通的未解决的符号,而不是依赖于libc.so.

2. 我该如何解决这个问题？

这里没有问题要解决.当您链接二进制文件时,您可以决定静态链接哪些库以及动态链接哪些库.

尝试手动添加-lssl似乎不起作用.

这应该工作:

gcc main.o -lthis -lssl

可能你做了类似的事情

gcc main.o -lssl -lthis

这是错误的:链接线上的库的顺序很重要.

如何编译二进制文件而不具有外部依赖性？

大多数操作系统都支持使用全静态二进制文件.一般来说,这应该不会是你的目标:它使更少的便携式的二进制文件,以及它们的使用是强烈反对.

如果您确实想要生成完全静态的二进制文件,请将其与-staticflag 链接.

为什么说完全静态不太便携？

因为他们是.

如果用户没有完全相同的lib构建,则二进制文件将不能与共享库一起移植,但可以使用静态移植.

这是不正确的:大多数共享库支持向后兼容性,例如libc.so.6版本2.22将很乐意运行与10年前版本2.3.6相关联的可执行文件.

如果你做ldd firefox

你需要注意你在做什么:

file -L `which /usr/bin/firefox`
/usr/bin/firefox: POSIX shell script, ASCII text executable

如果您查看shell脚本,您将发现它调用/usr/lib/firefox/firefox,并且该二进制文件是动态链接的:

ldd /usr/lib/firefox/firefox
    linux-vdso.so.1 =>  (0x00007ffca278d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f511731b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5117117000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5116e13000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5116b0d000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f51168f7000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5116532000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5117757000)