On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote: > > Is there a reason user C/C++ apps shouldn't be able to incorporate > libbacktrace, or is it just an oversight/TODO? It works beautifully if I > copy the relevant files to where they belong in the install tree [2]; it > also seems to work just fine when linked into apps compiled by older > versions of gcc (though I'm not sure how safe that is). The only real risk I > can think of is an app and a shared lib both linking in the static library, > but that should trigger the usual linker errors for duplicate symbols.
It is neither an oversight nor a TODO. It seems to me that libbacktrace is not really part of GCC, so installing GCC should not necessarily install libbacktrace. Also, of course, libbacktrace doesn't yet work on many important environments, including Mac OS and Windows. I think it's great if people find it useful. I'd be fine with a configure option to install libbacktrace if it defaults to not installing it. > [1] The ability to handle inlined funtions and shared library functions is > especially nice, as is its robustness against corrupted stack/heap. It also > works in spite of -fomit-frame-pointer. It's much more usable than unwind.h, > and beats the pants off the assorted non-portable hacks Google turns up. I'm glad you like it. Ian
