Find the answer to your Linux question:
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 ...
  1. #1
    Just 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,
    GCB
    Last edited by GCB-Toronto; 01-02-2012 at 06:37 PM.

  2. #2
    Just 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++".

  3. #3
    Linux Guru Rubberman's Avatar
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
...