This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Installing libbacktrace w/ gcc-4.8?
- From: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 17 May 2013 16:04:26 -0400
- Subject: Installing libbacktrace w/ gcc-4.8?
Hi all,
(Please CC me in replies, not a list member)
I'd like to use libbacktrace in a C++ app built by gcc-4.8.0 [1], but it
seems that the target library doesn't actually get installed, even
though it's built.
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.
[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.
[2] backtrace.h and backtrace-supported.h went into
$INSTALLDIR/lib/gcc/$TARGET/$VERSION/include/ (alongside unwind.h);
libbacktrace.la and libbacktrace.a went into $INSTALLDIR/lib64/
(alongside libssp, libasan, et al)
Thoughts?
Ryan