Tracking down undefined reference errors.

Discussion in 'C++' started by walkeraj@gmail.com, Nov 14, 2007.

  1. Guest

    I'm working on modifying an open source project that uses, among other
    things, SDL and CEGui. I went about it the smart way. I set up my
    mingw/msys/code::blocks environment first and then, one at a time, I
    went through all of the dependencies, compiling example programs with
    each one to make sure that they worked.

    Unfortunately, I am receiving linking errors with CEGUI, and I have no
    idea how to resolve them now. To compound the issue, the registration
    portion of their forums is broken and no one is responding to my
    request for manual registration. The errors I'm receiving are like
    this:

    --------
    obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    reference to `_imp___ZN5CEGUI6StringD1Ev'
    obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more undefined
    references to `_imp___ZN5CEGUI6StringD1Ev' follow
    obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    --------

    I know that this means that the linker cannot find the symbols that
    the object file is referring to. I know that these symbols don't mean
    anything right away to someone who doesn't know the libraries, but,
    since I can't reach anyone who DOES know, what I'm wondering is if
    there isn't some system I can use to track down these errors myself?

    Perhaps some way I can convert these symbol names into something
    useful that can help me track down what I need to be including? I
    know that linking order matters, and I think I know why, but I was
    wondering if someone could spell it out for me as well so I know that
    I have it right.
    , Nov 14, 2007
    #1
    1. Advertising

  2. Jim Langston Guest

    <> wrote in message
    news:...
    > I'm working on modifying an open source project that uses, among other
    > things, SDL and CEGui. I went about it the smart way. I set up my
    > mingw/msys/code::blocks environment first and then, one at a time, I
    > went through all of the dependencies, compiling example programs with
    > each one to make sure that they worked.
    >
    > Unfortunately, I am receiving linking errors with CEGUI, and I have no
    > idea how to resolve them now. To compound the issue, the registration
    > portion of their forums is broken and no one is responding to my
    > request for manual registration. The errors I'm receiving are like
    > this:
    >
    > --------
    > obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    > reference to `_imp___ZN5CEGUI6StringD1Ev'
    > obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more undefined
    > references to `_imp___ZN5CEGUI6StringD1Ev' follow
    > obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    > reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    > --------
    >
    > I know that this means that the linker cannot find the symbols that
    > the object file is referring to. I know that these symbols don't mean
    > anything right away to someone who doesn't know the libraries, but,
    > since I can't reach anyone who DOES know, what I'm wondering is if
    > there isn't some system I can use to track down these errors myself?
    >
    > Perhaps some way I can convert these symbol names into something
    > useful that can help me track down what I need to be including? I
    > know that linking order matters, and I think I know why, but I was
    > wondering if someone could spell it out for me as well so I know that
    > I have it right.


    Read up on name mangling. http://en.wikipedia.org/wiki/Name_mangling

    Most likely these would be calls to functions or methods named String and
    colour. Search for those in the code.
    Jim Langston, Nov 14, 2007
    #2
    1. Advertising

  3. Guest

    On Nov 14, 2:28 pm, "Jim Langston" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    >
    >
    > > I'm working on modifying an open source project that uses, among other
    > > things, SDL and CEGui. I went about it the smart way. I set up my
    > > mingw/msys/code::blocks environment first and then, one at a time, I
    > > went through all of the dependencies, compiling example programs with
    > > each one to make sure that they worked.

    >
    > > Unfortunately, I am receiving linking errors with CEGUI, and I have no
    > > idea how to resolve them now. To compound the issue, the registration
    > > portion of their forums is broken and no one is responding to my
    > > request for manual registration. The errors I'm receiving are like
    > > this:

    >
    > > --------
    > > obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    > > reference to `_imp___ZN5CEGUI6StringD1Ev'
    > > obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more undefined
    > > references to `_imp___ZN5CEGUI6StringD1Ev' follow
    > > obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    > > reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    > > --------

    >
    > > I know that this means that the linker cannot find the symbols that
    > > the object file is referring to. I know that these symbols don't mean
    > > anything right away to someone who doesn't know the libraries, but,
    > > since I can't reach anyone who DOES know, what I'm wondering is if
    > > there isn't some system I can use to track down these errors myself?

    >
    > > Perhaps some way I can convert these symbol names into something
    > > useful that can help me track down what I need to be including? I
    > > know that linking order matters, and I think I know why, but I was
    > > wondering if someone could spell it out for me as well so I know that
    > > I have it right.

    >
    > Read up on name mangling. http://en.wikipedia.org/wiki/Name_mangling
    >
    > Most likely these would be calls to functions or methods named String and
    > colour. Search for those in the code.


    Okay, so from this mangled name, I can tell that it's imported from a
    library, namespace: CEGUI, function name: String and that its return
    type is void. I don't know what D1 refers to, but I think the problem
    could be that these lib files are from an SDK that was built for
    visual Studio. Is it possible then that there is a difference in name-
    mangling convention here? If so, is there anything I can do to
    resolve it besides recompiling the CEGUI library in mingw?
    , Nov 14, 2007
    #3
  4. Stefan Guest

    wrote:
    > On Nov 14, 2:28 pm, "Jim Langston" <> wrote:
    >> <> wrote in message
    >>
    >> news:...
    >>
    >>
    >>
    >>> I'm working on modifying an open source project that uses, among other
    >>> things, SDL and CEGui. I went about it the smart way. I set up my
    >>> mingw/msys/code::blocks environment first and then, one at a time, I
    >>> went through all of the dependencies, compiling example programs with
    >>> each one to make sure that they worked.
    >>> Unfortunately, I am receiving linking errors with CEGUI, and I have no
    >>> idea how to resolve them now. To compound the issue, the registration
    >>> portion of their forums is broken and no one is responding to my
    >>> request for manual registration. The errors I'm receiving are like
    >>> this:
    >>> --------
    >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    >>> reference to `_imp___ZN5CEGUI6StringD1Ev'
    >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more undefined
    >>> references to `_imp___ZN5CEGUI6StringD1Ev' follow
    >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    >>> reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    >>> --------
    >>> I know that this means that the linker cannot find the symbols that
    >>> the object file is referring to. I know that these symbols don't mean
    >>> anything right away to someone who doesn't know the libraries, but,
    >>> since I can't reach anyone who DOES know, what I'm wondering is if
    >>> there isn't some system I can use to track down these errors myself?
    >>> Perhaps some way I can convert these symbol names into something
    >>> useful that can help me track down what I need to be including? I
    >>> know that linking order matters, and I think I know why, but I was
    >>> wondering if someone could spell it out for me as well so I know that
    >>> I have it right.

    >> Read up on name mangling. http://en.wikipedia.org/wiki/Name_mangling
    >>
    >> Most likely these would be calls to functions or methods named String and
    >> colour. Search for those in the code.

    >
    > Okay, so from this mangled name, I can tell that it's imported from a
    > library, namespace: CEGUI, function name: String and that its return
    > type is void. I don't know what D1 refers to, but I think the problem
    > could be that these lib files are from an SDK that was built for
    > visual Studio. Is it possible then that there is a difference in name-
    > mangling convention here? If so, is there anything I can do to
    > resolve it besides recompiling the CEGUI library in mingw?
    >

    My guess is that _imp___ZN5CEGUI6StringD1Ev refers to the destructor of
    the class CEGUI::String and that _imp___ZN5CEGUI6colourC1ERKS0_ refers
    to the construtor of class CEGUI::Colour.
    Stefan, Nov 15, 2007
    #4
  5. Guest

    On Nov 14, 3:59 pm, Stefan <> wrote:
    > wrote:
    > > On Nov 14, 2:28 pm, "Jim Langston" <> wrote:
    > >> <> wrote in message

    >
    > >>news:...

    >
    > >>> I'm working on modifying an open source project that uses, among other
    > >>> things, SDL and CEGui. I went about it the smart way. I set up my
    > >>> mingw/msys/code::blocks environment first and then, one at a time, I
    > >>> went through all of the dependencies, compiling example programs with
    > >>> each one to make sure that they worked.
    > >>> Unfortunately, I am receiving linking errors with CEGUI, and I have no
    > >>> idea how to resolve them now. To compound the issue, the registration
    > >>> portion of their forums is broken and no one is responding to my
    > >>> request for manual registration. The errors I'm receiving are like
    > >>> this:
    > >>> --------
    > >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    > >>> reference to `_imp___ZN5CEGUI6StringD1Ev'
    > >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more undefined
    > >>> references to `_imp___ZN5CEGUI6StringD1Ev' follow
    > >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    > >>> reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    > >>> --------
    > >>> I know that this means that the linker cannot find the symbols that
    > >>> the object file is referring to. I know that these symbols don't mean
    > >>> anything right away to someone who doesn't know the libraries, but,
    > >>> since I can't reach anyone who DOES know, what I'm wondering is if
    > >>> there isn't some system I can use to track down these errors myself?
    > >>> Perhaps some way I can convert these symbol names into something
    > >>> useful that can help me track down what I need to be including? I
    > >>> know that linking order matters, and I think I know why, but I was
    > >>> wondering if someone could spell it out for me as well so I know that
    > >>> I have it right.
    > >> Read up on name mangling. http://en.wikipedia.org/wiki/Name_mangling

    >
    > >> Most likely these would be calls to functions or methods named String and
    > >> colour. Search for those in the code.

    >
    > > Okay, so from this mangled name, I can tell that it's imported from a
    > > library, namespace: CEGUI, function name: String and that its return
    > > type is void. I don't know what D1 refers to, but I think the problem
    > > could be that these lib files are from an SDK that was built for
    > > visual Studio. Is it possible then that there is a difference in name-
    > > mangling convention here? If so, is there anything I can do to
    > > resolve it besides recompiling the CEGUI library in mingw?

    >
    > My guess is that _imp___ZN5CEGUI6StringD1Ev refers to the destructor of
    > the class CEGUI::String and that _imp___ZN5CEGUI6colourC1ERKS0_ refers
    > to the construtor of class CEGUI::Colour.


    Okay, so given the following:

    1) these are fundamental classes
    2) I have included all base libraries
    3) there are no errors are thrown at compile-time

    then it is likely to assume the mangled names are not resolving
    because the libraries were compiled with visual studio as opposed to
    mingw/gcc? If that's the case, how come some libraries (like
    SDL_image.lib) work? Is it because they use simpler functions whose
    names don't get mangled in an incompatible way?
    , Nov 15, 2007
    #5
  6. BobR Guest

    <> wrote in message...
    >
    > then it is likely to assume the mangled names are not resolving
    > because the libraries were compiled with visual studio as opposed to
    > mingw/gcc? If that's the case, how come some libraries (like
    > SDL_image.lib) work? Is it because they use simpler functions whose
    > names don't get mangled in an incompatible way?


    Why not run 'nm' on the lib in question to see what's in it?
    [ 'nm' is in the 'binutils' (MinGW) package. ]

    --
    Bob R
    POVrookie
    BobR, Nov 15, 2007
    #6
  7. Guest

    On Nov 15, 12:53 pm, "BobR" <> wrote:
    > <> wrote in message...
    >
    > > then it is likely to assume the mangled names are not resolving
    > > because the libraries were compiled with visual studio as opposed to
    > > mingw/gcc? If that's the case, how come some libraries (like
    > > SDL_image.lib) work? Is it because they use simpler functions whose
    > > names don't get mangled in an incompatible way?

    >
    > Why not run 'nm' on the lib in question to see what's in it?
    > [ 'nm' is in the 'binutils' (MinGW) package. ]
    >
    > --
    > Bob R
    > POVrookie


    Here are the first few entries it spit out:


    CEGUIBase.dll:
    00000000 i .idata$2
    00000000 i .idata$4
    00000000 i .idata$5
    00000000 i .idata$6
    007bc627 a @comp.id
    00000000 I __IMPORT_DESCRIPTOR_CEGUIBase
    U __NULL_IMPORT_DESCRIPTOR
    U CEGUIBase_NULL_THUNK_DATA

    CEGUIBase.dll:
    007bc627 a @comp.id
    00000000 I __NULL_IMPORT_DESCRIPTOR

    CEGUIBase.dll:
    007bc627 a @comp.id
    00000000 I CEGUIBase_NULL_THUNK_DATA

    CEGUIBase.dll:
    00000000 I .idata$4
    00000000 I .idata$5
    00000000 I .idata$6
    00000000 T .text
    00000000 T ??0?$RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@ABV01@@Z
    U __IMPORT_DESCRIPTOR_CEGUIBase
    00000000 I __imp_??0?
    $RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@ABV01@@Z

    CEGUIBase.dll:
    00000000 I .idata$4
    00000000 I .idata$5
    00000000 I .idata$6
    00000000 T .text
    00000000 T ??0?
    $RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@PAVBoundSlot@1@@Z
    U __IMPORT_DESCRIPTOR_CEGUIBase
    00000000 I __imp_??0?
    $RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@PAVBoundSlot@1@@Z

    CEGUIBase.dll:
    00000000 I .idata$4
    00000000 I .idata$5
    00000000 I .idata$6
    00000000 T .text
    00000000 T ??0?$RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@XZ
    U __IMPORT_DESCRIPTOR_CEGUIBase
    00000000 I __imp_??0?$RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@XZ

    CEGUIBase.dll:
    00000000 I .idata$4
    00000000 I .idata$5
    00000000 I .idata$6
    00000000 T .text
    00000000 T ??0?$Singleton@VFontManager@CEGUI@@@CEGUI@@QAE@XZ
    U __IMPORT_DESCRIPTOR_CEGUIBase
    00000000 I __imp_??0?$Singleton@VFontManager@CEGUI@@@CEGUI@@QAE@XZ
    , Nov 15, 2007
    #7
  8. Jim Langston Guest

    <> wrote in message
    news:...
    > On Nov 14, 3:59 pm, Stefan <> wrote:
    >> wrote:
    >> > On Nov 14, 2:28 pm, "Jim Langston" <> wrote:
    >> >> <> wrote in message

    >>
    >> >>news:...

    >>
    >> >>> I'm working on modifying an open source project that uses, among
    >> >>> other
    >> >>> things, SDL and CEGui. I went about it the smart way. I set up my
    >> >>> mingw/msys/code::blocks environment first and then, one at a time, I
    >> >>> went through all of the dependencies, compiling example programs with
    >> >>> each one to make sure that they worked.
    >> >>> Unfortunately, I am receiving linking errors with CEGUI, and I have
    >> >>> no
    >> >>> idea how to resolve them now. To compound the issue, the
    >> >>> registration
    >> >>> portion of their forums is broken and no one is responding to my
    >> >>> request for manual registration. The errors I'm receiving are like
    >> >>> this:
    >> >>> --------
    >> >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x157): undefined
    >> >>> reference to `_imp___ZN5CEGUI6StringD1Ev'
    >> >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x178): more
    >> >>> undefined
    >> >>> references to `_imp___ZN5CEGUI6StringD1Ev' follow
    >> >>> obj\Release\src\core\editor.o:editor.cpp:(.text+0x578): undefined
    >> >>> reference to `_imp___ZN5CEGUI6colourC1ERKS0_'
    >> >>> --------
    >> >>> I know that this means that the linker cannot find the symbols that
    >> >>> the object file is referring to. I know that these symbols don't
    >> >>> mean
    >> >>> anything right away to someone who doesn't know the libraries, but,
    >> >>> since I can't reach anyone who DOES know, what I'm wondering is if
    >> >>> there isn't some system I can use to track down these errors myself?
    >> >>> Perhaps some way I can convert these symbol names into something
    >> >>> useful that can help me track down what I need to be including? I
    >> >>> know that linking order matters, and I think I know why, but I was
    >> >>> wondering if someone could spell it out for me as well so I know that
    >> >>> I have it right.
    >> >> Read up on name mangling. http://en.wikipedia.org/wiki/Name_mangling

    >>
    >> >> Most likely these would be calls to functions or methods named String
    >> >> and
    >> >> colour. Search for those in the code.

    >>
    >> > Okay, so from this mangled name, I can tell that it's imported from a
    >> > library, namespace: CEGUI, function name: String and that its return
    >> > type is void. I don't know what D1 refers to, but I think the problem
    >> > could be that these lib files are from an SDK that was built for
    >> > visual Studio. Is it possible then that there is a difference in name-
    >> > mangling convention here? If so, is there anything I can do to
    >> > resolve it besides recompiling the CEGUI library in mingw?

    >>
    >> My guess is that _imp___ZN5CEGUI6StringD1Ev refers to the destructor of
    >> the class CEGUI::String and that _imp___ZN5CEGUI6colourC1ERKS0_ refers
    >> to the construtor of class CEGUI::Colour.

    >
    > Okay, so given the following:
    >
    > 1) these are fundamental classes
    > 2) I have included all base libraries
    > 3) there are no errors are thrown at compile-time
    >
    > then it is likely to assume the mangled names are not resolving
    > because the libraries were compiled with visual studio as opposed to
    > mingw/gcc? If that's the case, how come some libraries (like
    > SDL_image.lib) work? Is it because they use simpler functions whose
    > names don't get mangled in an incompatible way?


    Different compiler can/will use different name mangling. Most likely
    libraries like SDL_image.lib work because they use extern C linkage (no
    mangling). But it was always my understanding that a library for windows
    would not work in linux without recompiling and vice/versa. You should
    probalby recompile the libraries or check for extern C.
    Jim Langston, Nov 16, 2007
    #8
  9. James Kanze Guest

    On Nov 16, 12:25 am, wrote:
    > On Nov 15, 12:53 pm, "BobR" <> wrote:


    > > <> wrote in message...


    > > > then it is likely to assume the mangled names are not
    > > > resolving because the libraries were compiled with visual
    > > > studio as opposed to mingw/gcc? If that's the case, how
    > > > come some libraries (like SDL_image.lib) work? Is it
    > > > because they use simpler functions whose names don't get
    > > > mangled in an incompatible way?


    > > Why not run 'nm' on the lib in question to see what's in it?
    > > [ 'nm' is in the 'binutils' (MinGW) package. ]


    (There's also a c++filt program somewhere which unmangles g++
    mangled names.)

    > Here are the first few entries it spit out:


    [...]
    > 00000000 T ??0?$RefCounted@VBoundSlot@CEGUI@@@CEGUI@@QAE@ABV01@@Z

    [...]

    Not sure, but I think this is VC++ mangling. At any rate, g++
    doesn't use the @ character in its mangling scheme (and I think
    VC++ does). The names in your error message looked like they
    might be g++ mangling.

    You cannot link code compiled with g++ and code compiled with
    VC++. The two compilers use different class layouts (different
    organization of the vtable, etc.). If they happened to use the
    same mangling, and you managed to link the code, it would only
    crash when you tried to run the program. You have, basically,
    two choices: compile your code with VC++, or compile the all of
    the libraries you need with g++.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Nov 16, 2007
    #9
  10. BobR Guest

    James Kanze wrote in message...
    On Nov 16, 12:25 am, wrote:
    > On Nov 15, 12:53 pm, "BobR" wrote:


    /* """ quote

    > > Why not run 'nm' on the lib in question to see what's in it?
    > > [ 'nm' is in the 'binutils' (MinGW) package. ]


    (There's also a c++filt program somewhere which unmangles g++
    mangled names.)

    """ */

    "nm -C <objfile>" should do that too.

    'c++filt', 'ranlib', 'objdump', etc. are all in the 'binutils' package.

    And since it's a '*.dll', might also try the nm '-D' flag to see what it
    reports. There's also the 'dlltool' in binutils. That might get the files
    needed to compile the package. [I have not touched the DLL stuff in years,
    so, I'm not sure.]

    Another GNU package that might help the OP is 'LibTool'. Not so much the
    tool itself, but, the documentation. (search www.gnu.org ).

    Other than that, I agree with you, James.

    --
    Bob R
    POVrookie
    BobR, Nov 16, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    917
    Mark Goldin
    Jan 17, 2004
  2. Shuaib
    Replies:
    1
    Views:
    992
    Shuaib
    Aug 19, 2006
  3. boyphp
    Replies:
    2
    Views:
    290
    Victor Bazarov
    May 2, 2007
  4. Fred P
    Replies:
    6
    Views:
    2,226
    Fred Pacquier
    Oct 19, 2009
  5. Replies:
    4
    Views:
    181
    pkent
    Jan 14, 2004
Loading...

Share This Page