2

これが私のエラーです。

dyld: Symbol not found: __ZTIN8eqOsirix3ROIE
  Referenced from: /Users/slate/Documents/osirixplugins/CoreDataTrial_EQOsirix/build/Development/rcOsirix.app/Contents/MacOS/rcOsirix
  Expected in: flat namespace
 in /Users/slate/Documents/osirixplugins/CoreDataTrial_EQOsirix/build/Development/rcOsirix.app/Contents/MacOS/rcOsirix
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)
(gdb) bt
#0  0x8fe01065 in __dyld_dyld_fatal_error ()
#1  0x8fe04fa5 in __dyld__ZN4dyld4haltEPKc ()
#2  0x8fe0796b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#3  0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#4  0x8fe01057 in __dyld__dyld_start ()
(gdb) continue
Program received signal:  “EXC_BAD_ACCESS”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)
(gdb) bt
#0  0x8fe010e3 in __dyld__ZN13dyldbootstrapL30randomizeExecutableLoadAddressEPK12macho_headerPPKcPm ()
#1  0x8fe04fa5 in __dyld__ZN4dyld4haltEPKc ()
#2  0x8fe0796b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#3  0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#4  0x8fe01057 in __dyld__dyld_start ()
(gdb)

eqOsirix私のメインの名前空間はどこですか。少し前に2つの同様の問題（1つと2つ）がありましたが、どちらの解決策も今は役に立ちません。

Macをアップデートしてから気付きましたが、関係ないと思います。

コンパイル エラー (または警告) は生成されません。

何が原因でしょうか? リンク中にコンパイラが何もキャッチしないのはなぜですか? 私はクリーン ビルドを行い、XCode と Mac の両方をリセットしましたnamespace。オー！

[編集] @Troubador がそれはスクランブルの一部ではないと指摘したのでROI、以下に ROI を含めます。

#ifndef EQOSIRIX_ROI_H
#define EQOSIRIX_ROI_H

namespace eqOsirix{

    class ROI : public eq::Object
    {

    public:
        ROI() {};
        virtual ~ROI() {};

        virtual uint32_t getType() {return NONE;};

        virtual void draw() {};

    protected:

        enum ROIType {
            NONE = 0,
            LINE,
            POLY,
            AREA,
            VOLUME
        };

    private:

    };

}


#endif//EQOSIRIX_ROI_H

失敗することはあまりありません。C++ (Java や ObjC とは対照的に) ですべての仮想が正常に定義されていると思います。

4

1 に答える 1

1

あなたの質問に関する私たちの議論に基づいて、すべてのメソッドがクラス定義内で定義されているという事実と関係があると確信しています。これは、gcc には、typeinfo オブジェクトのシンボルを発行できる「キー」関数がないことを意味します。つまり、typeinfo オブジェクトを配置できる単一のオブジェクト ファイルはありません。したがって、gcc が行うことは、typeinfo シンボルを各オブジェクトに発行することです。ファイルを必要とし、リンカーが dylib を作成するときに重複を無視するように通知します。

可視性属性について尋ねた理由は、重複したシンボルの 1 つでも「非表示」としてマークされている場合、リンカーが dylib 内の typeinfo シンボルを非表示にし、アプリケーションの他の部分が実行時にそれを検索できなくなるためです。時間。報告している動作に適合すると思われるコンパイル時エラーは発生しません。

可視性属性を使用しているかどうかわからない場合は、デフォルトの可視性が基本的に非表示ではないことを意味する「デフォルト」であるため、使用していない可能性があります。-fvisibilityビルド ファイルで始まる gcc のオプションを探します。のようなものを使用して、可視性をコードでマークアップすることもできます__attribute__ ((visibility ("hidden")))。

cpp ファイル内で少なくとも 1 つのメンバー定義を移動することを提案した理由は、typeinfo オブジェクトを強制的に 1 回発行し、これが違いを生むかどうかをテストするためでした。あなたはこれを試したかどうかを言わなかったので、知っておくとよいでしょう.

于 2010-09-16T20:49:01.623 に答える