Tracking down undefined reference errors.

[walkeraj]

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.

 

[Jim Langston]

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.

 

[walkeraj]

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?

 

[Stefan]

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.

 

[walkeraj]

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?

 

[BobR]

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. ]

 

[walkeraj]

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. ]

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

 

[Jim Langston]

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.

 

[James Kanze]

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++.

 

[BobR]

James Kanze wrote in message...

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.