Dyld符号未找到错误

时间:2010-09-16 14:16:15

标签: c++ namespaces dyld

这是我的错误。

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是我的主命名空间。我不久前有两个类似的问题(onetwo),但现在这两个解决方案都没有帮助我。

我更新了我的mac后发现了问题,但我认为这是无关的。

不会生成编译错误(或警告)。

是什么导致这个?为什么编译器在链接期间没有捕获任何内容?我已经完成了干净的构建,重置了XCode和Mac ....我只是在结束时谷歌只给了我第三方框架的东西,但不包括在内但这是我的主要namespace !! Augh!


[编辑] 由于@Troubador指出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)???

1 个答案:

答案 0 :(得分:1)

基于我们对您的问题的讨论,我确信它与您在类定义中定义所有方法的事实有关。这意味着gcc没有“key”函数,它可以为typeinfo对象发出符号,即没有单个对象文件可以放置typeinfo对象。因此gcc做的是将typeinfo符号发送到每个对象中需要它的文件,并在创建dylib时通知链接器忽略重复项。

我询问可见性属性的原因是,即使其中一个重复的符号被标记为“隐藏”,链接器也会隐藏dylib中的typeinfo符号,而应用程序的任何其他部分都将无法查找在运行时。您将不会收到编译时错误,这似乎符合您要报告的行为。

如果您不确定是否使用可见性属性,那么您可能不是因为默认的可见性是“默认”,这基本上意味着没有隐藏。查找在构建文件中启动-fvisibility的gcc选项。 Visiblity也可以使用__attribute__ ((visibility ("hidden")))等内容在代码中标记。

我建议在cpp文件中移动至少一个成员定义的原因是强制单个发出typeinfo对象并测试这是否有所不同。你没有说你是否尝试过,所以最好知道。