> 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.
I agree. While I tend to build my own libelf/libdwarf/binutils, it
seems to be standard for a distro to ship a shared libelf and a static
libdwarf.
> 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.
Ah, OK -- I didn't notice that libdwarf wasn't compiled with PIC. That
explains why it's always a static library.
Is there any reason not to use the --whole-archive flags in one of the
Dyninst shared libraries, such symtabAPI or dynDwarf?
Alternatively, this could be handled via 'better documentation', as
mentioned. When I began to write code against Dyninst, it would have
been very helpful to have a sample application (e.g. create a BPatch
against argv[1] and exit) along with toolchain-specific build
commands. This could even use the configured build system, as long as
the build commands are echoed to STDOUT for reference. I tried to coax
the build commands out of the testsuite, but was not very successful.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}