Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
2 replies Latest Post - ‏2012-06-25T15:18:48Z by bdellegrazie
bdellegrazie
bdellegrazie
5 Posts
ACCEPTED ANSWER

Pinned topic Undefined Symbol when linking C++ executable to C++ shared module as C func

‏2012-06-21T11:50:34Z |
Hi,

I'm using AIX 6.1 with XLC 10.1 and I'm getting an undefined symbol error from the linker
when trying to link a simple C++ shared library (.so) containing a single function that is
used by both C and C++ programs (i.e. so the function is declared extern "C").

I have a C++ shared library containing this single function:

In testlib.cpp:
extern "C" int get_sum( int a, int b) {
return a+b;
}

In testlib.h
#ifndef TESTLIB_H
#define TESTLIB_H
extern "C" int get_sum( int a, int b);
#endif

This is compiled into testlib.so with an explicit export file containing:
#! libtestlib.so
get_sum
In test.cpp:
#include "testlib.h"
#include <stdio.h>
int main( int argc, char* argv[] ) {
printf( "Sum of 1 + 2 is: %d\r\n", get_sum( 1, 2 ) );
return 0;
}

When linking these two modules together I get an undefined symbol error from the
linker in the form:
ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
Symbol Inpndx TY CL Source-File(Object-File) OR Import-File{Shared-object}
RLD: Address Section Rld-type Referencing Symbol

.get_sum 44 ER PR test_cpp_linkage_as_c/test.cpp(CMakeFiles/test.dir/test.cpp.o)
00000024 .text R_RBR 24 .main

Implying the linker thinks test.cpp file is looking for .get_sum instead of get_sum even though the header
file specifies it as extern "C".

If I explicitly import the exports file on linking the test executable I get a duplicate symbol error as follows:
ld: 0711-228 WARNING: Duplicate symbols were found while resolving symbols.
The following duplicates were found:
Symbol Source-File(Object) OR Import-File{Shared-object}

-------------------------------------------------
.get_sum {libtestlib.so}
** Duplicate ** test_cpp_linkage_as_c/testlib/testlib.exp{libtestlib.so}
get_sum {libtestlib.so}
** Duplicate ** test_cpp_linkage_as_c/testlib/testlib.exp{libtestlib.so}

(base of paths were elided)

Can anyone suggest what it is I'm doing wrong to get these duplicates?

Actual Makefile and linker outputs showing everything are attached for convenience

Thanks,

Brett
Updated on 2012-06-25T15:18:48Z at 2012-06-25T15:18:48Z by bdellegrazie
  • flodstrom
    flodstrom
    57 Posts
    ACCEPTED ANSWER

    Re: Undefined Symbol when linking C++ executable to C++ shared module as C func

    ‏2012-06-25T11:36:27Z  in response to bdellegrazie
    How did you try to build the library and the binary (flags used, etc.)?

    I would not mess around with any export lists (making an easy thing more complex imho). I suspect that this may be one part of your problem.

    The code example should not even have gone through the compiler as-is (the syntax in the testlib.h header)? Perhaps something got mangled by the forum? Use the "code" markup to make sure things like C/C++ code is displayed correctly.

    Also as you may be aware of already? The terms shared object and shared library are somewhat misused and often refers to the same thing on many systems. AIX is more strict on this, a shared object really is just that a shared object! On AIX a shared object, shared library, run time link library, etc. can be completely different from each other!

    Due to this you have to make sure to build everything correctly according to what you want.
    • bdellegrazie
      bdellegrazie
      5 Posts
      ACCEPTED ANSWER

      Re: Undefined Symbol when linking C++ executable to C++ shared module as C func

      ‏2012-06-25T15:18:48Z  in response to flodstrom
      Hi flodstrom,

      Thank you for your response. Markup was definitely mangled (will use code next time).
      Actual commands used are visible in the original .txt file which is attached to the thread.

      I have now read up on the AIX shared object / shared library behaviour and will close this thread.
      I have a simpler, self-contained example.