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

[Jim Galarowicz <jeg@xxxxxxxxxxxxx>]

Thanks Bill, if you intend to link it in then maybe our build scripts 
are not passing something to the Dyninst build correctly.
Let me look and get back to you.

Thanks,
Jim G

On 03/11/2014 07:54 AM, Bill Williams wrote:
> We definitely try to link against a PIC libiberty.a, unless your CMake 
> configuration explicitly requests the GNU demangler instead. And if we 
> can't find one we'll try to download binutils and build it.
> Do you have the cmake output from when you configured Dyninst? That 
> should let me know what we did/didn't try to do.
> --bw
>
> On 03/10/2014 10: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.
> >
> >
> > _______________________________________________
> > Dyninst-api mailing list
> > Dyninst-api@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api