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

[Josh Stone <jistone@xxxxxxxxxx>]

On 03/11/2014 12:03 PM, Jim Galarowicz wrote:
> Hi Bill,
> 
> In response to your email (thanks Josh and Matt), I think I'm passing in 
> the correct parameters.
> Unless I'm supposed to pass something different than this, below:
>               CMakeCache.txt:IBERTY_LIBRARY:FILEPATH=/usr/lib64

You need the whole file path, not just the directory, e.g.
-DIBERTY_LIBRARY=/usr/lib64/libiberty.a

This works for me, but I intend to make the auto-detection work too.

> I've also attached some of the files from the top level directory.
> 
> I'm still seeing an undefined in libcommon.so for cplus_demangle.
> 
> [jeg@jeghost lib64]$ nm libcommon.so.8.2.0 | grep mangle
>                   U cplus_demangle
> 000000000002af80 t _Z10dedemanglePcS_
> 0000000000063b30 T _Z16P_cplus_demanglePKcbb
> 
> 
> build.txt is the screen output from the build that has this cmake line:
> + cmake . 
> -DCMAKE_INSTALL_PREFIX=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3 
> -DINSTALL_LIB_DIR=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3/lib64 
> -DINSTALL_INCLUDE_DIR=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3/include/dyninst 
> -DCMAKE_PREFIX_PATH=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3 
> -DCMAKE_BUILD_TYPE=RelWithDebInfo 
> -DLIBDWARF_LIBRARIES=/opt/krellroot_v2.1u3/lib64 
> -DLIBDWARF_INCLUDE_DIR=/opt/krellroot_v2.1u3/include 
> -DLIBELF_LIBRARIES=/usr/lib64 -DLIBELF_INCLUDE_DIR=/usr/include 
> -DPATH_BOOST= -DIBERTY_LIBRARY=/usr/lib64
> 
> 
> Thanks,
> Jim G
> 
> On 03/11/2014 11:51 AM, Josh Stone wrote:
>> On 03/11/2014 09:18 AM, Matthew LeGendre wrote:
>>> On Tue, 11 Mar 2014, Josh Stone wrote:
>>>> For the other option Bill mentioned, set cmake -DUSE_GNU_DEMANGLER=1,
>>>> which makes it use abi::__cxa_demangle from libstdc++ instead of
>>>> cplus_demangle from libiberty.  I'm not sure of pros/cons either way.
>>> The major con to using g++'s built-in demangler is that it can't
>>> handle binaries produced by the Portland Group Compiler.
>> OK, I see.  FWIW, binutils and libstdc++ have identical libiberty/
>> source directories, so all the demangling code is shared.  But only
>> cplus_demangle has the extra options parameter, which Dyninst uses to
>> set DMGL_ARM for pgCC.
>>
>> I wasn't going to bother with libiberty, since we obviously have
>> libstdc++ already, but this option control seems reason enough.
>> However, the build doesn't recognize that Fedora/RHEL libiberty.a is
>> PIC, so it falls back to the download method.  I'll see if that can be
>> fixed up...
>>
>> Josh
>>
>