This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Installing libbacktrace w/ gcc-4.8?


On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson
<ryan.johnson@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]