Re: [DynInst_API:] libiberty/libstdc++ demangler

[Matthew LeGendre <legendre1@xxxxxxxx>]

On Mon, 15 Jun 2015, Andrew Gontarek wrote:
> Hello list,
>
> I am running into an issue building dyninst with gcc/4.8.1. I get the 
> following error:
> > Linking CXX shared library libcommon.so
> > /usr/bin/ld: 
> > /opt/gcc/4.8.1/snos/lib/gcc/x86_64-suse-linux/4.8.1/../../../../lib64/libiberty.a(cplus-dem.o): 
> > relocation R_X86_64_32S against `_sch_istable' can not be used when making 
> > a shared object; recompile with -fPIC
> > /opt/gcc/4.8.1/snos/lib/gcc/x86_64-suse-linux/4.8.1/../../../../lib64/libiberty.a: 
> > could not read symbols: Bad value
> Looks like binutils wasn't built with -fpic. Trying to manually specify the 
> location of a known good iberty library compiled with -fpic resulted in no 
> luck. Providing the following cmake option resulted in the same error as 
> above:
> -DIBERTY_LIBRARIES=/usr/lib64/libiberty.a
>
> In the cmake/shared.cmake file, I found that uncommenting 
> set(USE_GNU_DEMANGLER 1) allowed dyninst to build. Is it alright to use the 
> libstdc++ demangler instead of libiberty? Are there any known side effects? 
> Thanks.
I'll let Bill or someone comment on the cmake configuration for 
finding/building a good libiberty.
But the main draw back of the GNU demangler is that it can't handle C++ 
names mangled by the Portland Group compiler.
-Matt