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

[Bill Williams <bill@xxxxxxxxxxx>]

On 06/15/2015 05:07 PM, 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
Weird; normally at least the /usr version of the demangler is built PIC. 
Does make VERBOSE=1 reflect the correct library search path for libiberty?
> 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.
Yes, it's fine; the binutils demangler in our experience has 
historically handled non-gcc name manglers somewhat better. I haven't 
tested recently to see whether that gap has closed--and there's no real 
reason for the binutils one to be superior.
> -Andrew

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx