Re: [DynInst_API:] Cannot link to dyninst 8.0 on Ubuntu

[Matthew LeGendre <legendre1@xxxxxxxx>]

Several comments inlined below:

On Tue, 26 Feb 2013, Andrew Bernat wrote:
> As you've noted, the build system is kind of complex. That's why we're 
> reluctant to change it.
> My opinion is that we should deprecate static dwarf support; is anyone 
> actively using it?
While I don't use a static libdwarf (I maintain some dynamic builds), I'd 
cast a vote against dropping support for it.  Static builds of libdwarf 
are the default distribution for that package and several distros.
Maybe it should get better documentation instead.

> On Feb 24, 2013, at 1:01 PM, mkfs <semper.non.sequitur@xxxxxxxxx> wrote:
>
> > Just a quick note -- the source code distro can be built to link
> > against the static DWARF library (thus resolving the missing .so
> > problem reported earlier) -- however, libsymtabAPI des not link to
> > this library correctly, so the dwarf symbols are all unresolved:
> >
> > bash$ g++ -I/usr/local/dyninst/include dyninst_test.cpp
> > -L/usr/local/dyninst/lib -ldyninstAPI -lcommon -lsymtabAPI -lpatchAPI
> > -lparseAPI -lstackwalk -lpcontrol -linstructionAPI -ldynC_API
> > -ldynDwarf -ldynElf -lsymLite -lsymtabAPI
> > /usr/local/dyninst/lib/libdynDwarf.so: undefined reference to
> > `dwarf_get_fde_info_for_cfa_reg3'
> > /usr/local/dyninst/lib/libsymtabAPI.so: undefined reference to `dwarf_errmsg'
> > /usr/local/dyninst/lib/libsymtabAPI.so: undefined reference to `dwarf_dieoffset'
> > /usr/local/dyninst/lib/libsymtabAPI.so: undefined reference to `dwarf_lowpc'
> > ...
> > bash$
> >
> >
> > This can be fixed by linking against libdwarf.a correctly in the
> > application build:
> >
> > bash$ g++ -I/usr/local/dyninst/include dyninst_test.cpp
> > -L/usr/local/dyninst/lib -ldyninstAPI -lcommon -lsymtabAPI -lpatchAPI
> > -lparseAPI -lstackwalk -lpcontrol -linstructionAPI -ldynC_API
> > -ldynDwarf -ldynElf -lsymLite -lsymtabAPI -Wl,--whole-archive
> > /usr/lib/libdwarf.a -Wl,--no-whole-archive
> > bash$
> >
> >
> > The requirement for the --whole-archive...--no-whole-archive archive
> > flags in GNU ld are somewhat new and broke a lot of my own projects
> > (which tend to build a single shared library from many static
> > libraries) a few years back. It appears this fix was applied to at
> > least part of the Dyninst build process, as the flag appears in the
> > test suite for PPC code:
> >
> > bash$ grep -rI ldwarf .
> > ...
> > ./testsuite/ppc64_bgq_ion/Makefile:MYLINK_FLAGS += -Wl,--whole-archive
> > -ldwarf -Wl,--no-whole-archive
> > ...
> >
> >
> > The proper fix is to use the --whole-archive flags in the build for
> > either libdynDwarf.so (the obvious place) or libsymtabAPI.so (where
> > all the libdwarf symbols seem to be referenced). Unfortunately, the
> > build system is rather baroque, and I couldn't find the proper place
> > to change "-ldwarf" to "-Wl,--whole-archive -ldwarf
> > -Wl,--no-whole-archive".
If you did want to change this in Dyninst you'd find it in the 
dyninst/make.library.tmpl file, under the USES_DWARF_DEBUG lines, but 
that's not the proper fix.
If you try to link libdwarf.a into libdynDwarf.so you get errors about 
libdwarf.a having incorrect relocation types--because libdwarf.a is not 
built with -fPIC.
The solution you're using is the right one.  You have to add libdwarf.a to 
the executable command line, and you have to specify the whole-archive 
option.
> > Have you considered using libtool to manage the building of the shared
> > libraries? It takes a day or two to get used to, but it should ease
> > the maintenance of the build system long-term.
There are many reasons why libtool and automake would be great 
improvements to the Dyninst build system, but they wouldn't help here. 
The core problem is how libdwarf.a was built.  As a static archive it has 
to be linked with the executable, and that's outside of Dyninst's control.
-Matt