1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] [RFC] On libunwind and USE=unwind

    From Sam James@21:1/5 to All on Thu Jul 17 08:40:01 2025
    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?

    thanks,
    sam

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Sam James on Thu Jul 17 16:50:02 2025
    On Thu, 2025-07-17 at 07:29 +0100, Sam James wrote:
    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).


    Is llvm-runtimes/libunwind usable for that as well or not? Either way,
    I'm all of getting rid of sys-libs/libunwind if we can get away with it,
    if only because it simplifies the situation with two libunwinds.

    --
    Best regards,
    Michał Górny

    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmh5C54SHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOxR8IAK7OPRqPqZGamWmzH2edhovWBvT8swX4 j5D+tCD2N6/Eb/H5/AwRFzXV/02WRiMQtBhBNulFfCGGKESKL7c/lyXQ99mLm9TI Bsf8amL1hUTT+LwI5CN78oXLXHqnTuDOEBSX8Y4P/HcVfAstavru7bCvbJBT/IZl AA8P4l+WeWh47zfki1R8j5hgFCNWqqe3zK1XbMQ9FwSn6NWWlQDPO/e9AgjtNvUK fN9zlwK1bHJ5BAMholUfPKKGZ5ryTJvwTQHAOcRA0jA0MpyyMVu6pf8JLKdYqAmc BPKU/kjNIU/Vn146g/Zl+C/6PULlOHdcGIY/Neps0iwGXp55QMsWoog=
    =Rsrh
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to Sam James on Thu Jul 17 16:50:02 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Schwartz@21:1/5 to Sam James on Thu Jul 17 17:00:01 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------S0ICT0PtAMEpXo4sawAc1AMP
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    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

    --------------S0ICT0PtAMEpXo4sawAc1AMP--

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCaHkOcwUDAAAAAAAKCRCEp9ErcA0vVzCP AQDC2PeH0gdKYA6npDMrpTsTaOkTx3GPytcf1fikTCAL6QD/Z7ECauGK9z5ZDAXEfZTvUVE2ZKk+ BdyUE8/LQ7dV+w0=
    =7jr8
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexey Sokolov@21:1/5 to All on Thu Jul 17 16:40:01 2025
    * 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?


    This could be mitigated by making it e.g. USE=elfutils-unwind

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)