Re: [DynInst_API:] libcommon.so -> undefined reference to `cplus_demangle'

[Jim Galarowicz <jeg@xxxxxxxxxxxxx>]

Hi Dyninst team,

I was wrong about it working on Fedora 19.  It fails there in the same way as on Fedora 20.  I need to beef up the build failure detection.

Thanks,
Jim G

On 03/10/2014 08:36 PM, Jim Galarowicz wrote:

Hi Dyninst team,

I'm looking for some advice on how to resolve, in a reasonable fashion a linking error I'm seeing.

I'm trying to link the OpenSpeedShop utility: osswrapper using the new 8.2 git tree dyninst but I'm getting an undefined from libcommon for cplus_demangle.

I'm seeing the issue on Fedora 20.  I did not have trouble linking on Fedora 19 after I added an extra dyninst libs variable to our ax_dyninst.m4 file and used that in the linking of osswrapper.

DYNINST_EXTRA_LIBS="$BINUTILS_IBERTY_LIB $LIBELF_LIBS $LIBDWARF_LIBS "
DYNINST_EXTRA_LDFLAGS="$BINUTILS_IBERTY_LDFLAGS $LIBELF_LDFLAGS $LIBDWARF_LDFLAGS"

I then added the @DYNINST_EXTRA_LIBS@ and @DYNINST_EXTRA_LDFLAGS@ into my Makefile.am file where I'm linking osswrapper.
I already had LIBELF_LDFLAGS, LIBELF_LIBS and LIBDWARF_LDFLAGS/LIBDWARF_LIBS in the Makefile because they are required by the dyninst libraries too.  So, I combined them all into the extra libs/ldflags variables.

However, that doesn't seem to work on Fedora 20, where there must be a different linking order in place?

Anyway, that triggered a bigger question about linking in needed libraries when using dyninst.
If libiberty is an archive as it seems to be on the Fedora systems I have access to, shouldn't that just be linked into libcommon.so by the dyninst build?

I can get it to link on Fedora 20 but I had to add the libiberty path and library name into the dyininst lib list in our m4/ax_dyninst.m4 file.   Seems kind-of hokey to me, so I'm asking for advice on this.

DYNINST_LIBS="-ldyninstAPI -lcommon $BINUTILS_IBERTY_LDFLAGS $BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI -lpatchAPI -lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite"

Here is the original link issue: (where -liberty is present, but not right after libcommon).

libtool: link: g++ -DLIBDIR=\"/opt/cbtf_only_v1.1u1/lib64\" -DXMLDIR=\"/opt/cbtf_only_v1.1u1/share/KrellInstitute/xml\" -I../include -pthread -I/opt/cbtf_only_v1.1u1/include -I/opt/cbtf_only_v1.1u1/include -I/opt/cbtf_only_v1.1u1/include -I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/include/dyninst -DUSE_STL_VECTOR -std=c++0x -I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/lib64/mrnet-4.0.0/include -I/opt/krellroot_v2.1u3/lib64/xplat-4.0.0/include -Dos_linux -g -O2 -DLIB_DIR=lib64 -o .libs/collectionTool collectionTool-collectionTool.o -Wl,--whole-archive -Wl,--no-whole-archive  -L../src -L/opt/cbtf_only_v1.1u1/lib64 -L/opt/krellroot_v2.1u3/lib64 -lboost_program_options -lboost_filesystem -lboost_system -lboost_thread -lcbtf -lcbtf-mrnet -lcbtf-xml -liberty -lelf -lxerces-c /home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-symtabapi.so -ldwarf -lcommon -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf -ldynDwarf -lsymLite /home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-mrnet.so -lmrnet -lxplat -lpthread /home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core.so /opt/cbtf_only_v1.1u1/lib64/libcbtf-messages-perfdata.so -lltdl -ldl -pthread -Wl,-rpath -Wl,/opt/cbtf_only_v1.1u1/lib64
/opt/krellroot_v2.1u3/lib64/libcommon.so: undefined reference to `cplus_demangle'
collect2: error: ld returned 1 exit status
make: *** [collectionTool] Error 1


[dew@localhost collectionTool]$ ldd /opt/krellroot_v2.1u3/lib64/libcommon.so
    linux-vdso.so.1 =>  (0x00007fff083fe000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fc6ae3d8000)
    libm.so.6 => /usr/lib64/libm.so.6 (0x00007fc6ae0d0000)
    libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fc6adeba000)
    libc.so.6 => /usr/lib64/libc.so.6 (0x00007fc6adafb000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003434e00000)

[dew@localhost collectionTool]$ nm /opt/krellroot_v2.1u3/lib64/libcommon.so | grep " U "
                 U abort@@GLIBC_2.2.5
                 U __assert_fail@@GLIBC_2.2.5
                 U calloc@@GLIBC_2.2.5
                 U ceilf@@GLIBC_2.2.5
                 U closedir@@GLIBC_2.2.5
                 U close@@GLIBC_2.2.5
                 U cplus_demangle
                 U ctime@@GLIBC_2.2.5
                 U __cxa_atexit@@GLIBC_2.2.5
                 U __cxa_begin_catch@@CXXABI_1.3
                 U __cxa_end_catch@@CXXABI_1.3
                 U __cxa_guard_abort@@CXXABI_1.3
                 U __cxa_guard_acquire@@CXXABI_1.3
                 U __cxa_guard_release@@CXXABI_1.3

[dew@localhost collectionTool]$ lsr /usr/lib64/libiber*
460 -rw-r--r--. 1 root root 469744 Aug 30  2013 /usr/lib64/libiberty.a
[dew@localhost collectionTool]$

[dew@localhost m4]$ diff ax_dyninst.m4-seemedToWork ax_dyninst.m4
Key for diffs
< works
> does not

107,110c107,110
<             DYNINST_LIBS="-ldyninstAPI -lcommon $BINUTILS_IBERTY_LDFLAGS $BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI -lpatchAPI -lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite"
<             DYNINST_EXTRA_LIBS="$LIBELF_LIBS $LIBDWARF_LIBS "
<             DYNINST_EXTRA_LDFLAGS="$LIBELF_LDFLAGS $LIBDWARF_LDFLAGS"
<             DYNINST_SYMTABAPI_LIBS="-lcommon $BINUTILS_IBERTY_LDFLAGS $BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf -ldynDwarf -lsymLite"
---
>             DYNINST_LIBS="-ldyninstAPI -lcommon -lsymtabAPI -linstructionAPI -lparseAPI -lpatchAPI -lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite"
>             DYNINST_EXTRA_LIBS="$BINUTILS_IBERTY_LIB $LIBELF_LIBS $LIBDWARF_LIBS "
>             DYNINST_EXTRA_LDFLAGS="$BINUTILS_IBERTY_LDFLAGS $LIBELF_LDFLAGS $LIBDWARF_LDFLAGS"
>             DYNINST_SYMTABAPI_LIBS="-lcommon -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf -ldynDwarf -lsymLite"
[dew@localhost m4]$


Any suggestions?

Thanks,
Jim G.