2

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

Community
  • 1
  • 1
Stephen Furlani
  • 6,794
  • 4
  • 31
  • 60
  • It's the typeinfo for eqOsirix::ROI that's missing. Do you use gcc's visibility attributes in your code? – Troubadour Sep 16 '10 at 14:27
  • lol I thought the ROI was part of the scramble... uhm, since I don't know what the visibility attributes are I'm guessing no. – Stephen Furlani Sep 16 '10 at 14:43
  • Okay, thanks. It might be explained by the answers to [g++ undefined reference to typeinfo](http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo). See if any of those help. – Troubadour Sep 16 '10 at 14:51
  • I put up the code for `eqOsirix::ROI`... I don't see anything wrong? – Stephen Furlani Sep 16 '10 at 15:07
  • `ROI` looks fine. The problem may be with the base `eq::Object`. (BTW, you have a lot of redundant semi-colons in the definition of `ROI`. You don't need them after the closing brace of a function definition.) – Troubadour Sep 16 '10 at 15:15
  • yeah, I was experimenting with `= 0;` and forgot to take em out. – Stephen Furlani Sep 16 '10 at 15:20
  • Actually I'm not so sure the problem is in the base. If you define one of your virtual members, eg. the DTOR, in the corresponding cpp file (rather than in the class definition) then it might work. If you have no cpp file then either stick it in an existing one temporarily to test this or create one. – Troubadour Sep 16 '10 at 15:21
  • since the class was almost purely virtual, I stuck it in the header of a subclass and it worked. *no* idea why. – Stephen Furlani Sep 16 '10 at 18:04
  • What did you put in the subclass header? The definition of the DTOR? – Troubadour Sep 16 '10 at 19:36
  • the whole class definition of `ROI` is now in the header for `ROILine` a subclass. – Stephen Furlani Sep 16 '10 at 19:39
  • That's just bizarre. FWIW I've added an answer to try to explain my various comments. Perhaps with the background you'll be able to figure out what's going on in your particular situation. – Troubadour Sep 16 '10 at 20:50

1 Answers1

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.

Troubadour
  • 13,334
  • 2
  • 38
  • 57