Dyld Symbol not Found Ошибка

Question

Вот моя ошибка.

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 - мое основное пространство имен. У меня было две аналогичные проблемы некоторое время назад (one и two), но ни одно решение не помогает мне сейчас.

Я заметил проблему после того, как обновил свой mac, но я думаю, что это не связано.

Не генерируются ошибки компиляции (или предупреждения).

Что может быть причиной этого? Почему компилятор ничего не ловит во время компоновки? Я сделал чистые сборки, сбросил как XCode, так и Mac ... Я просто нахожусь в конце, и Google просто дает мне материал для сторонних разработчиков, которые не включены, но это мой главный namespace !! Augh!

---

[EDIT] Поскольку @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) ???

Answer 1

Основываясь на нашем обсуждении по вашему вопросу, я уверен, что он имеет какое-то отношение к тому, что все ваши методы определены в определении класса. Это означает, что gcc не имеет «ключевой» функции, рядом с которой он может выделять символ для объекта typeinfo, т. Е. Нет единого объектного файла, в который может быть помещен объект типаinfo. Таким образом, gcc поэтому должен испускать символ типаinfo в каждый объект файл, который требует его, и сообщить компоновщику игнорировать дубликаты при создании dylib.

Причина, по которой я спросил об атрибутах видимости, заключается в том, что если даже один из дублированных символов помечен как «скрытый», тогда компоновщик скроет символ типаinfo в пределах dylib, и любая другая часть вашего приложения не сможет его просмотреть во время выполнения. Вы не получите ошибку времени компиляции, которая, похоже, соответствует поведению, о котором вы сообщаете.

Если вы не уверены, используете ли вы атрибуты видимости, вы, вероятно, не так, поскольку по умолчанию видимость является «по умолчанию», которая в основном означает не скрытую. Найдите варианты gcc, которые начнут -fvisibility в ваших файлах сборки. Visiblity также может быть помечен в коде с использованием таких вещей, как __attribute__ ((visibility ("hidden"))).

Причина, по которой я предложил переместить хотя бы одно определение члена внутри файла cpp, было принудительное одиночное излучение объекта typeinfo и проверить, не изменилось ли это. Вы не сказали, пытались ли вы это или нет, так что было бы хорошо знать.