Ошибка Dyld Symbol не найдена

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

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 и два), но ни одно из решений мне сейчас не помогает.

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

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

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


[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) ???


person Stephen Furlani    schedule 16.09.2010    source источник
comment
Отсутствует информация о типе для eqOsirix::ROI. Используете ли вы атрибуты видимости gcc в своем коде?   -  person Troubadour    schedule 16.09.2010
comment
лол, я думал, что ROI был частью борьбы ... хм, поскольку я не знаю, что такое атрибуты видимости, я предполагаю, что нет.   -  person Stephen Furlani    schedule 16.09.2010
comment
Хорошо спасибо. Это может быть объяснено ответами на неопределенная ссылка g++ на typeinfo. Посмотрите, поможет ли кто-нибудь из них.   -  person Troubadour    schedule 16.09.2010
comment
Выставил код для eqOsirix::ROI... не вижу ничего плохого?   -  person Stephen Furlani    schedule 16.09.2010
comment
ROI выглядит нормально. Проблема может быть с базой eq::Object. (Кстати, у вас есть много избыточных точек с запятой в определении ROI. Они вам не нужны после закрывающей скобки определения функции.)   -  person Troubadour    schedule 16.09.2010
comment
да, я экспериментировал с = 0; и забыл их вынуть.   -  person Stephen Furlani    schedule 16.09.2010
comment
На самом деле я не уверен, что проблема в базе. Если вы определяете одного из ваших виртуальных членов, например. DTOR в соответствующем файле cpp (а не в определении класса), тогда это может сработать. Если у вас нет файла cpp, временно вставьте его в существующий, чтобы проверить его, или создайте его.   -  person Troubadour    schedule 16.09.2010
comment
так как класс был почти чисто виртуальным, я воткнул его в шапку подкласса и все заработало. понятия не имею почему.   -  person Stephen Furlani    schedule 16.09.2010
comment
Что вы поместили в заголовок подкласса? Определение DTOR?   -  person Troubadour    schedule 16.09.2010
comment
все определение класса ROI теперь находится в заголовке для ROILine подкласса.   -  person Stephen Furlani    schedule 16.09.2010
comment
Это просто странно. FWIW Я добавил ответ, чтобы попытаться объяснить мои различные комментарии. Возможно, с фоном вы сможете понять, что происходит в вашей конкретной ситуации.   -  person Troubadour    schedule 17.09.2010


Ответы (1)


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

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

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

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

person Troubadour    schedule 16.09.2010
comment
Спасибо за помощь. Моя жизнь наполнена такими причудливыми вещами, как работа с Objective-C++... - person Stephen Furlani; 17.09.2010
comment
@Стивен Фурлани: лол! Это мило. Кстати, не стесняйтесь не принимать мой ответ и добавлять правильный ответ самостоятельно. - person Troubadour; 29.09.2010