强制 GCC 通知共享库中未定义的引用
我有一个与另一个（第三方）共享库链接的共享库。然后在我的应用程序中使用 dlopen 加载我的共享库。所有这些工作正常（假设文件位于正确的路径等）。
现在的问题是，当我链接我的库时，我什至不需要指定链接到第三方共享库。 GCC 接受它，而不报告有关未定义引用的错误。所以，问题是； 如何强制 GCC 通知我有关未定义的引用？
如果我将库更改为（暂时）可执行文件，我会得到未定义的引用（当不向链接器提供库时）。 （如果我指定它，则效果很好。）
即，完成以下操作：
g++ -fPIC -shared -o libb.so b.o
g++ -fPIC -shared -o liba.so a.o
g++ -o a.exe a.cpp
第二行不给出错误，第三行抱怨未定义的引用。
示例代码：
ah:
class a
{
public:
void foobar();
};
a.cpp:
#include "a.h"
#include "b.h"
void a::foobar()
{
b myB;
myB.foobar();
}
int main()
{
a myA; myA.foobar();
}
bh:
class b
{
public:
void foobar();
};
b.cpp:
#include "b.h"
void b::foobar()
{
}
I have a shared library that is linked with another (third-party) shared library. My shared library is then loaded using dlopen in my application. All this works fine (assuming files are in the proper path etc).
Now, the problem is that I don't even need to specify to link against the third-party shared library when I link my library. GCC accept it without reporting errors about undefined references. So, the question; how can I force GCC to notify me about undefined references?
If I change my library to be (temporarily) an executable, I get undefined references (when not supplying the library to the linker). (Works fine if I specify it.)
I.e., the following is done:
g++ -fPIC -shared -o libb.so b.o
g++ -fPIC -shared -o liba.so a.o
g++ -o a.exe a.cpp
Where the second line does NOT give out an error and the third line complains about an undefined reference.
Sample code:
a.h:
class a
{
public:
void foobar();
};
a.cpp:
#include "a.h"
#include "b.h"
void a::foobar()
{
b myB;
myB.foobar();
}
int main()
{
a myA; myA.foobar();
}
b.h:
class b
{
public:
void foobar();
};
b.cpp:
#include "b.h"
void b::foobar()
{
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
构建共享库时可以使用
-Wl,--no-undefined链接器选项，未定义的符号将显示为链接器错误。-Wl,--no-undefinedlinker option can be used when building shared library, undefined symbols will be shown as linker errors.经过更多研究，我意识到这些东西是如何工作的。有两个链接器选项可以操作共享库的未定义符号：
第一个是
--no-undefined。它报告在链接阶段未立即解析的未解析符号。除非在链接的共享库中找到该符号，否则手动（使用-l开关）或自动（libgcc_s，C++ 运行时；libc，C 运行时；ld-linux-**.so，动态链接器 utils) 选择，--no-undefined将其报告为错误。这就是提问者所需要的关键。还有另一个键，
--no-allow-shlib-undefined（其描述也表明--no-undefined）。它检查您将共享库链接到的共享库中的定义是否满足。该键在本主题所示的情况下用处不大，但它可能很有用。然而，它也有其自身的障碍。联机帮助页提供了一些关于为什么它不是默认值的基本原理：
事实是，上面所说的也是正确的，例如，对于 Linux 系统，共享库的一些内部例程是在 ld-linux 中实现的。 so，动态加载器（它既是可执行文件又是共享库）。除非您以某种方式链接它，否则您将得到类似这样的信息：
这些是来自加载程序 ld-linux.so 的未定义引用。它是特定于平台的（例如，在我的系统上，正确的加载程序是
/lib64/ld-linux-x86-64.so）。您可以将加载器与您的库链接起来，甚至检查上面显示的棘手参考：After more research, I realized what way the stuff works. There are two linker options to manipulate undefined symbols of shared libraries:
First one is
--no-undefined. It reports the unresolved symbols that are not resolved immediately, at linking stage. Unless the symbol is found in a shared library linked against, either manually (with-lswitch) or automatically (libgcc_s, C++ runtime;libc, C runtime;ld-linux-**.so, dynamic linker utils) picked,--no-undefinedreports it as error. That's the key the questioner needed.There is another key,
--no-allow-shlib-undefined(whose description also suggests--no-undefined). It checks if definitions in the shared libraries which you link your shared library against are satisfied. This key is of little use in the case shown in this topic, but it can be useful. However, It has its own obstacles.The manpage provides some rationale about why it's not default:
The thing is that what is said above is also true, for example, for Linux systems, where some of the internal routines of the shared library is implemented in
ld-linux.so, the dynamic loader (it's both executable and shared library). Unless you somehow link it, you will get something like this:These are undefined references from the loader,
ld-linux.so. It is platform-specific (for example, on my system the correct loader is/lib64/ld-linux-x86-64.so). You may link the loader with your library and check even the tricky references shown above: