まず、我々は、入手可能な情報を見て、検索を開始するためにそれを使用することができます。 Linuxを使用しているときには、GCCまたはClangのシンボルが表示されている可能性が高いので、これは良いスタート地点です。GNU manglingスキームに関する情報を探すことができます。
次に、シンボル内のパターンを探します。数字は文字列中の文字の総数である複数の1つの数字から複数の文字列があります。これはこれらが名前であることを示している可能性があります。
我々はシンボルZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7
を取り、にそれを打破することができ、ことを考慮:PDF "Calling Conventions"(pg.38)に記載GNU3-4マングルスキームに従って、今
Z
N
5Gnome
5Glade
3Xml
6create
E
R
K
S
s
R
K
N
4Glib
7ustring
E
S
7
、名はエンコードされていますよう:
<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にシンボルを供給し、このリンクによるとa link to the class' reference.得ることができる、ということを考慮すると、関数は次のように定義されます
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())
はチェックを倍増するために、我々は、関数のマングルされた名前がどうなるかを決定することができます、そのパラメータリストを使用して:
直接、その後示唆正しいシンボルを生成しなかった
cout
から
typeid(Gnome::Glade::Xml::create).name()
を出力し、(、
Glib::RefPtr<T>
ため
Glib::ustring
、および
Gnome::Glade::Xml
をダミーのクラスを使用して)簡単なC++プログラムでこれを入れて
static Glib::RefPtr<Xml>
Gnome::Glade::Xml::create (const std::string &filename,
const Glib::ustring &root=Glib::ustring(),
const Glib::ustring &domain=Glib::ustring());
チャマングリングスキームかABIのどちらかでnge。より具体的には、Ss
の代わりにstd::string
をNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
と変更しました。 a bit of digging aroundの後、これはGCC 5.1以降のバージョンの変更によるものです。マクロ_GLIBCXX_USE_CXX11_ABI
は古いものの代わりに新しいstring
(および新しい名前)を使用することを示します。これは、問題の原因を示す可能性もあります(この記事の最後を参照)。
これを考慮すると、古いスキームを使用して関数の名前を手作業でmangleし、シンボルに一致するかどうかを確認するのが最善です。第三のパラメータとして
<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
したがって、3番目のパラメータはS7_
です。これを考慮し、最終シンボルである:ユーティリティサイトに次のデマングルシンボルでDemangler.com結果、これを食べさせる
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.
:PDFの状態として
Gnome::Glade::Xml::create(std::string const&, Glib::ustring const&, Glib::ustring const&)
を戻り値の型が含まれていないこと通常の機能のためのマングリングスキームでは、これは正しいと思われます。
上記のように、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;
}
は、このコードを取ることによって、私は、第1の出力にtypeid
に機能-c
コンパイラオプションでファイルをコンパイルした後、最初の2 #include
sおよびmain()
の身体をコメントアウト記号、および出力シンボルリストを使用しましたnm main.o
。 typeid
シンボルと一致しなかったが、nm
によって表示名があった:
// With macros commented out:
_ZN5Gnome5Glade3Xml6createERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKN4Glib7ustringESD_
// With macros active:
_ZN5Gnome5Glade3Xml6createERKSsRKN4Glib7ustringES7_
二つ目は、エラーメッセージに記載されたシンボルと同一であるように、これは、マングリング方式は依然として同じであることを示しているとしたがって、問題を解決するには、次のとおりです。
あなたがリンクしようとしているオブジェクトファイルがGCCの異なるバージョン(またはあなたが使用していた方GCC互換コンパイラ)でコンパイルされた、または1つが_GLIBCXX_USE_CXX11_ABI
マクロでコンパイルされたいずれかの0
に設定し、もう一方は設定しませんでした。