Results 1 to 3 of 3
I am compiling and linking a large 'C' project using the CodeLite IDE and GCC.
For some modules in the project I am getting "undefined reference" linker errors on all ...
- 01-02-2012 #1Just Joined!
- Join Date
- Jan 2012
- Posts
- 2
GCC "undefined reference" error
I am compiling and linking a large 'C' project using the CodeLite IDE and GCC.
For some modules in the project I am getting "undefined reference" linker errors on all function calls made in certain modules.
All modules are compiled with exactly the same switches.
My current guess is that some of my modules are getting compiled as simple "C" language and others are getting compiled as "C++". My reasoning on this is below.
A typical such linker error would be:
HORIZONA.C:178: undefined reference to `report_error(unsigned short, char const*, char const*, int)'
Looking at the GCC assembler output it appears that the calling module is mangling the name of the called function. For example when calling the "report_error" function:
.loc 1 178 0
movl $178, 12(%esp)
movl $__ZL4file, 8(%esp)
movl $LC0, 4(%esp)
movl $2, (%esp)
call __Z12report_errortPKcS0_i
Note that report_error has leading and trailing tags added.
In a successfull call to report_error I am seeing:
.loc 1 417 0
movl $417, 12(%esp)
movl $_file, 8(%esp)
movl $LC1, 4(%esp)
movl $5, (%esp)
call _report_error
as expected.
Also, the function definitions within such a module are also mangled, such as:
.text
.globl __Z13horizona_initv
.def __Z13horizona_initv; .scl 2; .type 32; .endef
__Z13horizona_initv:
instead of the expected
.text
.globl _horizona_init
.def _horizona_init; .scl 2; .type 32; .endef
_horizona_init:
Other modules that do not produce the linker errors do not exhibit this kind of name mangling.
The strange thing is the inconsistency - some modules have this problem and others do not.
The solution to this might have something to do with name mangling or decoration, or calling conventions.
As noted above my current guess is that some of my modules are getting compiled as simple "C" language and others are getting compiled as "C++". All modules are compiled with exactly the same command line switches. I am thinking there may be a #define or #ifdef in some header file causing this. If I add extern "C" to a header file:
extern "C" {
extern BOOL horizona_init(void);
extern BOOL horizona_setup(COM_SETUP_PARAMS);
extern BOOL horizona_remove(COM_REMOVE_PARAMS);
extern BOOL horizona_take_request(COM_TAKE_PARMS);
}
extern "C" is accepted in one "C" module but not another.
Does anyone know of a compile switch either on the command line or in a header file that cause control the compile language ("C" or "C++" ?).
Any help would be greatly appreciated.
Thanks,
GCBLast edited by GCB-Toronto; 01-02-2012 at 06:37 PM.
- 01-03-2012 #2Just Joined!
- Join Date
- Jan 2012
- Posts
- 2
Turned out to be something simple. If you pass GCC a .c file it compiles "C". If you pass GCC a .C file it compiles "C++".
- 01-04-2012 #3Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
This sort of problem is not uncommon when moving source files from Windows (which is case-insensitive by default) to Linux/Unix, which is totally case-sensitive. When moving C files from Windows to Linux/Unix, I always convert the names to all lower-case for just this reason. Welcome to the land of cross-platform development!
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!


Reply With Quote