On Fri, May 17, 2013 at 5:36 PM, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote: > On 17/05/2013 6:18 PM, Ian Lance Taylor wrote: >> >> 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. > > Ah... I had gotten the impression that it was special sauce, part of gcc > (like unwind.h is). Can it be built and installed stand-alone, then?
Yes, pretty much. The build uses a couple of header files in the GCC distribution, but not in any essential way. In fact there is a patch I need to review to make even that aspect of it simpler. http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00766.html Ian
