Sam James <[email protected]> writes: > Hi! > > sys-libs/libunwind was the main library for providing backtraces on > crashes (think of e.g. Xorg's logging) for quite some time, but it > doesn't support a bunch of features like our splitdebug Portage FEATURE > properly. > > It's also considered deprecated upstream, in search of a new maintainer, > and doesn't work with Intel CET (a hardening feature). > > I think the main splitdebug problem is > https://github.com/libunwind/libunwind/issues/286, if anyone's curious. > > In a bunch of ebuilds, we currently have USE=unwind to control libunwind > use where there's also a dependency on dev-libs/elfutils that is > separately controlled: > > * dev-debug/ltrace > * dev-debug/strace > * dev-lang/ghc > * dev-libs/elfutils > * dev-util/perf > * media-libs/gstreamer > * x11-apps/igt-gpu-tools > > elfutils is far preferred for this, and I'd like to encourage migration > to it. > > How should we handle this? > > Some options: > * Should we make USE=unwind mean "use elfutils" in cases where both > are supported? > * Related: What about cases where USE=unwind exists and actually causes > libunwind > to be used over elfutils right now? > * If not, should we have USE=elfutils (which feels very vague and that > it is unilkely users will want to turn that on, its purpose isn't > obvious) for those?
parona and I discussed this, where he'd suggested along the lines of: * USE=unwind controls the feature * USE=libunwind controls the provider, and we'd prefer elfutils (so USE=unwind would mean elfutils usually) i.e. give it the usual "provider" treatment like IM/GM and ffmpeg/libav and so on, and that seems like obviously the best path now I heard it ;) > > thanks, > sam sam
