为什么-O转换为gcc会导致"stat"解决? [英] Why does -O to gcc cause "stat" to resolve?

问题描述

试图进行搜索，但未找到任何内容.每当我尝试编译共享库和链接到它的测试二进制文件时，都会出现此错误:

Tried to do a search, but didn't find anything. Whenever I try to compile a shared object and the test binary that links to it I get this error:

[root@hypervisor test-files]# ./test
./test: symbol lookup error: ./test-files.so: undefined symbol: stat
[root@hypervisor test-files]#

在使用它后，我发现如果在编译期间将-O馈送到gcc，则stat()将按预期开始工作.我一直无法在线找到关于-O为何所有问题修复带有未定义符号的问题的指示(或者它只是掩盖错误而不是解决错误?).

After playing around with it I found that if I feed -O to gcc during the compile, stat() starts working as expected. I haven't been able to find any indication online as to why -O of all things fixes a problem with an undefined symbol (or does it just mask an error instead of fixing it?).

推荐答案

该优化很可能触发了删除不可达代码的操作，从而完全消除了对符号的需要.

In all likelihood, the optimization triggered removal of unreachable code, removing the need for the symbol altogether.

构建test-files.so共享库时，可能没有使用C编译器，而是直接调用了ld.因此，将不存在test-files.so所具有的任何库依赖关系.动态加载文件会使其尝试使用test二进制文件中可用的符号来解析符号，而找不到该符号.

When you built the test-files.so shared object, you likely did not use the C compiler but invoked ld directly. Thus, any library dependencies that test-files.so had would not be present. Loading the file dynamically would make it attempt to resolve the symbols with those already available within your test binary, and it could not be found.

通过优化进行编译会删除称为stat的无法访问的代码，因此在调用dlopen()时不需要解析该符号.

Compiling with the optimization removed the unreachable code that called stat, and so the symbol did not need to be resolved on the call to dlopen().

这篇关于为什么-O转换为gcc会导致"stat"解决?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！