ianlancetaylor / libbacktrace

A C library that may be linked into a C/C++ program to produce symbolic backtraces

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Packaging libbacktrace

wookey opened this issue · comments

I tried email to Ian Lance Taylor iant@golang.org but got no response, so trying here instead.

I looked at packaging your libbacktrace (from
https://github.com/ianlancetaylor/libbacktrace) because a trivial fork
of it (https://github.com/tlc-pack/libbacktrace) is used by Apache
TVM, which I am packaging for Debian/Ubuntu.

Firstly, I see that it only builds a static library. Is that a
technical limitation to do with the backtracing or the way it is
intended to be used, (or something to do with there being no
ABI-stability guarantees like libiberty) or just a 'no-one asked for a
dynamic version yet' thing?

Obviously in distro-world we'd normally build a dynamic version (and a
static version) and use them as required. So I'm just wondering if
there is a reason why I shouldn't do that?

Re the fork. The only change is this:(and 3 lines of whitespace)
tlc-pack@08f7c7e
which I think is irrelevant on linux as we are not normally looking at macho-0 binaries).

If it's useful then maybe that one-line change could go upstream and
there might be one fewer pointless fork in the world :-)
If I'm understanding right it may be related to : #78

Cheers for any pointers you can give,

Wookey

The libbacktrace library explicitly supports being invoked from a signal handler, but that most likely won't work if it is linked in as a dynamic library. So in normal use, without additional information, it should be linked statically.

I committed the one line patch that you mentioned.

Nothing else to do here. Thanks.

The libbacktrace library explicitly supports being invoked from a signal handler, but that most likely won't work if it is linked in as a dynamic library

Hi @ianlancetaylor ! I'm interested in building the dynamic library version and using it in a signal handler (via Boost.Stacktrace). Could you elaborate on why static linking is the only option in this case?

My concern is that lazy PLT calls may not work reliably if invoked via a signal handler. I don't know whether this concern is completely valid. It can be obviated by using -Wl,-z,now when linking.