符号查找错误：.so.2未定义符号

Question

如何解决这个未定义的符号。

odroid @ odroid：〜/ flycapture.2.9.3.43_armhf / bin $ sudo ./FlyCap2 ./FlyCap2：符号查找错误：/usr/lib/libflycapturegui.so.2：未定义符号： ZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7

odroid@odroid:~/flycapture.2.9.3.43_armhf/bin$ sudo ldconfig -v | grep fly

/sbin/ldconfig.real: Path `/lib/arm-linux-gnueabihf' given more than once
/sbin/ldconfig.real: Path `/usr/lib/arm-linux-gnueabihf' given more than once
/sbin/ldconfig.real: /lib/arm-linux-gnueabihf/ld-2.23.so is the dynamic linker, ignoring
/sbin/ldconfig.real: /usr/lib/libflycapture.so.2 is not a symbolic link
/sbin/ldconfig.real: /usr/lib/libflycapturegui.so.2 is not a symbolic link

libflycapture.so.2 -> libflycapture.so.2.9.3.43
libflycapturegui.so.2 -> libflycapturegui.so.2.9.3.43

---

odroid@odroid:~/flycapture.2.9.3.43_armhf/bin$ ls -lah /usr/lib | grep fly

-rw-r--r--   1 root root 473K Jul 13 13:26 libflycapturegui.so
-rw-r--r--   1 root root 473K Jul 13 13:26 libflycapturegui.so.2
-rw-r--r--   1 root root 473K Jul 13 13:26 libflycapturegui.so.2.9.3.43
-rw-r--r--   1 root root 3.3M Jul 13 13:26 libflycapture.so
-rw-r--r--   1 root root 3.3M Jul 13 13:26 libflycapture.so.2
-rw-r--r--   1 root root 3.3M Jul 13 13:26 libflycapture.so.2.9.3.43

Answer 1

首先，我们可以查看可用的信息，并使用它来开始搜索。 当您使用Linux时，它很可能是GCC或Clang错位符号，它为我们提供了一个良好的起点：我们可以查找有关GNU重整方案的信息。

接下来，查找符号中的模式。 有多个一个多个字母的字符串，其中数字是字符串中的字母总数; 这可能表明这些是名字。

考虑到这一点，我们可以采用符号ZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7 ，并将其分解为：

Z
N
5Gnome
5Glade
3Xml
6create
E
R
K
S
s
R
K
N
4Glib
7ustring
E
S
7

现在，根据PDF“调用约定” （第38页）中描述的GNU3-4修改方案，名称编码为：

<public name>    ::= _Z <qualified name>
<qualified name> ::= N [<simple name>]<sup>∞</sup><sub>2</sub> E
    There are a minimum of 2 "simple name" symbols.
<simple name>    ::= <name length> <name>
    "Name length" is a decimal number indicating the length of "name".
Nested names are listed inwards, with the leftmost one being the outermost.

我们可以用它来拼凑一个部分符号，其含义如下：

Symbol: _ZN5Gnome5Glade3Xml6createE
Means : The symbol's qualified name is "Gnome::Glade::Xml::create".
Note  : At least one underscore appears to have been dropped by the error message.

考虑到它之后的垃圾和名称本身，这是一个函数符号。 因此，考虑到这一点，我们可以将符号提供给Google，并获取该类参考的链接。 根据此链接，该功能定义为：

Class  :   Gnome::Glade::Xml
Section: "Static Public Member Functions"
Full declaration:
    static Glib::RefPtr< Xml >
    create (const std::string &filename, const Glib::ustring &root=Glib::ustring(),
            const Glib::ustring &domain=Glib::ustring())

要仔细检查，我们可以使用该参数列表确定函数的错位名称：

static Glib::RefPtr< Xml >
Gnome::Glade::Xml::create (const std::string &filename,
                           const Glib::ustring &root=Glib::ustring(),
                           const Glib::ustring &domain=Glib::ustring());

直接将它放在一个简单的C ++程序中（使用Glib::RefPtr<T> ， Glib::ustring和Gnome::Glade::Xml伪类），然后输出typeid(Gnome::Glade::Xml::create).name()到cout没有生成正确的符号，这表明修改方案或ABI的变化。 更具体地说， std::string被破坏为NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE ，而不是预期的Ss 。 经过一番挖掘 ，我发现这是由于GCC 5.1及更高版本的变化，其中宏_GLIBCXX_USE_CXX11_ABI指示使用新string （和新名称）而不是旧string 。 这也可能表明问题的原因（参见本文末尾）。

因此，考虑到这一点，最好使用旧方案手动破坏函数的名称，并查看它是否与符号匹配。

<public name> ::= <simple or qualified name> [<parameter type>]<sup>∞</sup><sub>1</sub>
    There is a minimum of 1 "parameter type" symbols.

Name      : Gnome::Glade::Xml::create
Parameters:
    const std::string&   : RKSs
        "RK" is "Reference (R), const (K)", and "Ss" is a special symbol for std::string.
    const Glib::ustring& : RK4Glib7ustringE
        "RK" is followed by the type's "qualified name".
    const Glib::ustring& : RK4Glib7ustringE

由于第三个参数是第三个参数的副本，因此它使用缩写规则，其中Sx_是缩写符号。 根据PDF，每个用户定义的类型名称，命名空间名称和非简单类型都分配了一个缩写，但实体名称本身不是。 因此...

S0_ : 5Gnome
S1_ : 5Glade
S2_ : 3Xml
S3_ : Ss
S4_ : RKSs
S5_ : 4Glib
S6_ : 7ustring
S7_ : RK4Glib7ustringE

因此，第三个参数是S7_ 。 考虑到这一点，最终的符号是：

Name          : _ZN5Gnome5Glade3Xml6createE
Parameter list: RKSsRKN4Glib7ustringES7_
    Parameters:
        RKSs              : const std::string&
        RKN4Glib7ustringE : const Glib::ustring&
        S7_               : const Glib::ustring&
Symbol        : _ZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7_
    Two underscores were apparently dropped somewhere, one on each end.

将此信息提供给公用事业网站Demangler.com会产生以下符号：

Gnome::Glade::Xml::create(std::string const&, Glib::ustring const&, Glib::ustring const&)

由于PDF声明返回类型不包含在正常函数的修改方案中，因此这似乎是正确的。

---

现在，如上所述，ABI已更改，导致修改方案和/或库类型名称发生更改。 所以，为了检查这个，我做了一点测试。

// main.cpp
//#undef  _GLIBCXX_USE_CXX11_ABI
//#define _GLIBCXX_USE_CXX11_ABI 0

//#include <iostream>
//#include <typeinfo>
#include <string>


namespace Glib {
    template<typename T>
    class RefPtr {};

    class ustring {};
}

namespace Gnome {
    namespace Glade {
        class Xml {
          public:
            static Glib::RefPtr< Xml >
            create (const std::string &filename,
                    const Glib::ustring &root=Glib::ustring(),
                    const Glib::ustring &domain=Glib::ustring());
        };
    }
}

Glib::RefPtr< Gnome::Glade::Xml >
Gnome::Glade::Xml::create (const std::string &filename,
                           const Glib::ustring &root /*=Glib::ustring()*/,
                           const Glib::ustring &domain /*=Glib::ustring()*/) {
                               return Glib::RefPtr<Gnome::Glade::Xml>();
                           }

int main() {
//    std::cout << typeid(const std::string&).name() << std::endl;
//    std::cout << typeid(Gnome::Glade::Xml::create).name() << std::endl;

//    std::cout << typeid(std::string).name() << std::endl;
}

通过获取此代码，我首先使用typeid输出函数符号，然后注释掉前两个#include s和main()的主体，使用-c编译器选项编译文件，并输出带有nm main.o的符号列表nm main.o 。 虽然typeid与符号不匹配，但nm显示的名称为：

// With macros commented out:
_ZN5Gnome5Glade3Xml6createERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKN4Glib7ustringESD_

// With macros active:
_ZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7_

由于第二个与错误消息中提到的符号相同，这表明修改方案仍然相同，因此问题的解决方案是：

您尝试链接的目标文件是使用不同版本的GCC（或您正在使用的GCC兼容编译器）编译的，或者是在_GLIBCXX_USE_CXX11_ABI宏设置为0而另一个未编译的情况下编译的。

Answer 2

我在尝试在arch linux上安装flycapture时遇到了同样的问题。 最终我发现有一个更新版本的flycapture（2.11.3.121）没有这个问题。