Question

Here s my error.

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)

where eqOsirix is my main namespace. I had two similar problems a while ago (one and two) but neither solution is helping me now.

I noticed the problem after I updated my mac, but I think it s unrelated.

No compile errors are generated (or warnings).

What could cause this? Why isn t the compiler catching anything during linking? I ve done clean builds, reset both XCode and the Mac.... I m just at wit s end and Google just gives me stuff for 3rd party Frameworks not being included but this is my main namespace!! Augh!

[EDIT] Since @Troubador pointed out that ROI wasn t part of the scramble, I m including ROI below:

#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

not much to screw up, and I think I have all the virtuals defined ok for C++ (as opposed to Java or ObjC) ???

Answer 1

Based on our discussion on your question I m sure it has something to do with the fact that all your methods are defined within the class definition. This means that gcc has no "key" function alongside which it can emit the symbol for the typeinfo object i.e. there is no single object file that the typeinfo object can be placed in. What gcc therefore does is to emit the typeinfo symbol into each object file that requires it and inform the linker to ignore duplicates when it creates the dylib.

The reason I asked about the visibility attributes is that if even one of the duplicated symbols is marked as "hidden" then the linker will hide the typeinfo symbol within the dylib and any other part of your application will fail to look it up at run-time. You will not get a compile time error which seems to fit the behaviour you are reporting.

If you are not sure if you are using visibility attributes then you probably are not since the default visiblity is "default" which basically means not hidden. Look for options to gcc that start -fvisibility in your build files. Visiblity can also be marked up in code using things like __attribute__ ((visibility ("hidden"))).

The reason I suggested moving at least one member definition inside a cpp file was to force a single emission of the typeinfo object and test whether this made a difference. You didn t say whether you tried this or not so it would be good to know.

友情链接