問題タブ [name-mangling]

次の行のコードが少しあります

このコードを使用するプロジェクトは、構成タイプ32ビットのC ++ Visual Studio 2010を使用してコードをコンパイルすると正常に機能します（私も32ビットWindowsマシンを使用しています）。

マシンを64ビットに変更し、C ++ Visual Studio 2010でコンパイルするx64構成を使用すると、リンクエラーが発生します。

C ++の名前マングリングは32ビットと64ビットで異なりますか？もしそうなら、64ビットC ++の名前マングリング規則はどこにありますか？

を使用して、Lion を実行している Macbook で OpenCV の i386 フレーバーをローカルにビルドしました。

ライブラリは正常にビルドおよび公開され、xcode プロジェクトに追加しました。ただし、テスト アプリのビルド時にリンク エラーが発生し、名前マングリングの問題のようです。

Undefined symbols for architecture i386: "cv::namedWindow(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)", referenced from: _main in main.o "cv::imread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)", referenced from: _main in main.o "cv::imshow(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cv::_InputArray const&)", referenced from: _main in main.o

cv::imread を例にとると、libopencv_highgui.dylib から次の名前でエクスポートされます。

main.o がシンボルを参照している間

一方、__ZN2cv7waitKeyEi同じ dylib リンクからの関数は問題ありません。

テスト アプリとフレームワークの両方が i386 arch 用です。

この問題を引き起こしている可能性のあるアイデアはありますか?

コードを MySQL Connector C++ 1.1.0 とリンクすると、未解決の外部シンボル エラーが発生します。
エラーメッセージは次のとおりです。

mysqlconn dumpbin-static.lib でシンボルのリストを取得していたところ、同様のシンボルが見つかりました。

この 2 行を並べると、違いは次のようになります。

YAPEAVANDの名前管理の違いは何YAPAVですか?

私の問題は、MySQL コネクタ ライブラリとコードのビルド方法との間の非互換性に関連していると考えられます。

ウェブを検索したところ、MySQL Connector 1.1.0 に対するバグが見つかりましたが、「バグではない」に変更されました。

64 ビット プラットフォームを使用して 32 ビット ターゲットにコンパイルする Visual Studio 2010 を使用しています。
MySQL コネクタ C++ はバージョン 1.1.0 です。

これに相当する C++ コンパイラを使用して C コードベースを構築する状況があります。

lib.h

lib.c

main.c

C++03 Standard Annex C Compatibility C.1.2 Clause 3で指摘されているため、 extern を追加する必要がありました。 (でコンパイルする-fpermissiveと、敷物の下でこれを一掃します。)

ちなみに、valuesobjdump での表示方法の違いは、次のようになりexternます。

...そして、追加後は次のようになります。

したがって、名前マングリングは削除され、「L」が「G」に変わり、リンカはvalues未定義であることについて文句を言いません。

同じ状況で、2 つの非常によく似たファイルを同じ方法で変更したとします。

tmp-exttypes.h

a-lib.c

これらは、クリーンにビルドされた、プロジェクト内の 2 つの Reb_To_RXT 定義のみです。しかし、それはリンクしていません。それについて言及している2つのファイルのみをobjdumpすると、次のようになります。

Lと書いてあり、名前がバラバラです。これは、はるかに単純な例を満足させるものではありませんでした。しかし、extern が出現するたびにこれがどのように発生するのか疑問に思っています。これが喫煙銃であると信じるのは正しいですか...そして、一般的に、externとしてのみ宣言されたものにローカルリンケージを持たせるべきではないということはどこにもありませんか?

gcc でコンパイルされたプログラムをプロファイリングしているときに、foo.isra.3. とはどういうisra意味ですか? 関数の 1 つがいくつかの場所でしか呼び出されず、引数の 1 つが常にリテラル値として指定されていることに気付きました。多分それは、特定の引数用に最適化された関数のバリアントであることを意味しますか?

関数をエクスポートする静的ライブラリがあります

コンパイル後、その名前は次のようにマングルされます

使用しようとすると、VS がエラーを返す

そして、何が悪いのかわかりません。同じ関数が異なる方法でマングルされるのはなぜですか? 同じ Visual Studio で両方のプロジェクトをコンパイルしました。クラスには単一のヘッダーがあります。

助けてください。

C ++プログラムの逆アセンブルを見ると、のような関数があり_Z41__static_initialization_and_destruction_0ii.constprop.221ます。constpropこの場合の意味は何ですか？外観はisra接尾辞に似ているように見えますが（たとえば、組み合わされることもあります.isra.124.constprop.226）、それは別の意味を持ちます。

これが私がしたことです：

から.hファイルを変更しました

に

コードを再コンパイルしました (問題ありません)。変更は somelib.so (多くのso ファイルの 1 つ) に行われました。次に、機器の古い so をこれに置き換えましたが、so をロードするときに次のエラーが発生しました。 undefined symbol: _ZN13KeypathHelper11getCacheObjEv

ここで奇妙なのは、このクラスはこの so ファイルでのみ使用されると言われたことです (どうすれば確認できますか?)。私はそれほど経験がなく、調査方法がわかりません。どんな提案でも大歓迎です。

アップデート

この特定の問題は、別のファイルが KeypathHelper クラスを使用していたため、それを含むファイルのみを置き換えたために発生しました。他に更新する必要があるものを見つける方法は、KeypathHelper のすべての so を grep することでした。

私はいくつかの sparc ライブラリを持っており、実名を持つエクスポート関数のリストが必要です。objdump または nm を使用して、__1cEnameIcopyType6MpnIASN1CTXT_rnLAsn1TObject_4_v_またはのような名前を取得__1cHsurname2t5B6M_v_するので、c++filt はそれらをデマングルできません。nm が持っているすべてのスタイル (gnu、lucid、arm、hp、edg、gnu-v3、java、gnat) を試しましたが、結果は同じです。手伝っていただけませんか？

MS C/C++ 静的にリンクされたリリース exe (デバッグ情報なし)がありますが、これはシンボルをエクスポートしませんが、16 進ビューアーで参照すると、次のようなものが表示されます。

もちろん、それらは内部 C++ モジュールによって提供される特定のクラス/メンバーのマングル名です。

なぜ彼らはそこにいるのですか？どうすればそれらを公開するのを避けることができますか?