On 7/17/25 10:46 AM, Sam James wrote:
> 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 ;)


That was my first thought when reading your initial email, too. "unwind"
is a feature name, not a library dependency name, therefore it should
only be used to indicate the feature (which *coincidentally* in many
ebuilds may only offer a single provider called "lib" unwind).


-- 
Eli Schwartz

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to