> 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. _______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
