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]

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


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