强制GCC通知共享库中未定义的引用

时间:2010-03-01 13:46:28

标签: c++ shared-libraries dynamic-linking

我有一个与另一个(第三方)共享库链接的共享库。然后在我的应用程序中使用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 

第二行没有发出错误,第三行抱怨未定义的引用。

示例代码:

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()
{
}

3 个答案:

答案 0 :(得分:42)

构建共享库时,可以使用

-Wl, - no-undefined 链接器选项,未定义的符号将显示为链接器错误。

  

g ++ -shared -Wl,-soname,libmylib.so.5 -Wl, - no-undefined -o libmylib.so.1.1 mylib.o -lthirdpartylib

答案 1 :(得分:16)

经过更多的研究,我意识到这些东西的运作方式。有两个链接器选项可以操作共享库的未定义符号:

第一个是--no-undefined。它报告在链接阶段未立即解决的未解析符号。除非在链接的共享库中找到符号,否则手动(使用-l切换)或自动(libgcc_s,C ++运行时; libc,C运行时; ld-linux-**.so,选择动态链接器utils,--no-undefined将其报告为错误。这是提问者所需要的关键。

还有另一个密钥--no-allow-shlib-undefined(其描述也建议--no-undefined)。它会检查是否满足共享库中与您的共享库相关联的中的定义。在本主题中显示的情况下,此键很少使用,但它可能很有用。但是,它有自己的障碍。

该联机帮助页提供了一些关于它为什么不是默认值的理由:

   --allow-shlib-undefined
   --no-allow-shlib-undefined
       Allows  (the  default)  or  disallows  undefined  symbols  in  shared
       libraries (It is meant, in shared libraries _linked_against_, not the
       one we're creating!--Pavel Shved). This switch is similar to --no-un-
       defined except  that it determines  the  behaviour when the undefined
       symbols are in a shared library rather than a regular object file. It
       does not  affect  how  undefined  symbols in regular object files are
       handled.

       The  reason  that  --allow-shlib-undefined is the default is that the
       shared library being specified at link time may not be  the  same  as
       the one that is available at load time, so the symbols might actually
       be resolvable at load time.  Plus there are some systems,  (eg  BeOS)
       where  undefined  symbols in shared libraries is normal.  (The kernel
       patches them at load time to select which function is most  appropri-
       ate for the current architecture.  This is used for example to dynam-
       ically select an appropriate memset function).  Apparently it is also
       normal for HPPA shared libraries to have undefined symbols.

上面所说的也是如此,例如,对于Linux系统,其中共享库的一些内部例程是在ld-linux.so中实现的,动态加载器(它既可执行又共享)图书馆)。除非你以某种方式链接它,否则你会得到类似的东西:

/lib64/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
/usr/lib64/gcc/x86_64-suse-linux/4.3/libstdc++.so: undefined reference to `__tls_get_addr@GLIBC_2.3'
/lib64/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'

这些是来自加载程序ld-linux.so的未定义引用。它是特定于平台的(例如,在我的系统上,正确的加载程序是/lib64/ld-linux-x86-64.so)。您可以将加载程序链接到库,并检查上面显示的棘手的引用:

g++ -fPIC -shared -o liba.so a.o -Wl,--no-allow-shlib-undefined  /lib64/ld-linux-x86-64.so.2

答案 2 :(得分:1)

你不能让ld(这是gcc正在运行的)注意链接中没有的库。您可以关闭RTLD_LAZY以获得积极的报告,并且您可以添加在链接之后立即运行的单元测试,以清除这些问题。