---
title: External Dependency Timelines
tags: steering, rustc
breaks: false
---
# External Dependency Timelines
Sometimes changes in rustc depend on support in external tooling, such as name mangling or debuginfo.

- Merging a change without external support..
- ..can break workflows when users upgrade to new rustc versions (external tools no longer work or crash).
- Waiting for external support..
- ..can take years.
- ..significantly extends time to get feedback on implementations.
- In the worst case, discovering an implementation issue requires waiting for external tools to be updated again.
- ..reduces contribution.
- It isn't fun to make a change and need to wait years to see it used.

We currently have no defined policy on how long to wait before merging or enabling changes in these areas. As a consequence, changes waiting on external dependencies can get blocked as nobody is quite sure when "long enough to wait" is.

There are various factors we might consider in deciding how long to wait for a given dependency/change:

- How widely used is the tool with Rust?
- Does the nature of the regression matter?
- Is use of the tool with Rust is completely broken or is it just a degraded experience?
- Is waiting for a new release enough, or does it need to be broadly available?
- Do we wait until it is available in popular Linux distributions?
- What if vendors only support the most recent version (which have support) but older versions (without support) are more frequently used?

All of the above assume that a patch has been landed in the dependent project, however:

- What if we can't get a patch landed upstream?
- What if a contributor isn't interested in making a patch upstream?
- Is a patch always necessary?
- What if the other project takes considerable time to review/merge/release?

## Examples
There are recent examples of changes being delayed in rustc until external dependencies have added support for the change:

- v0 name mangling ([rust-lang/rust#60705](https://github.com/rust-lang/rust/issues/60705))
- Implemented in Jan 2019
- Submitted support to `libiberty` in Mar 2020
- Landed in `libiberty` in Nov 2020
- Submitted to Valgrind in Jan 2021
- Pulled from `libiberty` to binutils/gdb in Jan 2021
- Landed in Valgrind in Sep 2021
- Available in gdb 10.2 released in Apr 2021
- Landed in lldb in Jun 2021
- Available in Valgrind 3.19 in Apr 2022
- See [recent steering meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202023-04-28.20v0.20mangling.20compiler-team.23609/near/353886897)

## Tools
Any policy we adopt may have specific policies for specific tools, depending on the release cycle of the tool, or the importance of its dependency. As such, it may be worthwhile to consider the example of specific tools during policy discussion, a non-exhaustive list is included below:

Tool | Dependency | Release cycle | Typical install method
---- | ---------- | ------------- | ----------------------
GNU GCC | Name Mangling + Debuginfo | [Yearly][gnu_release_cycle] | Distros
LLVM | Name Mangling + Debuginfo | [Six months][llvm_release_cycle] | Distros + Vendor
Valgrind | Name Mangling | [Six months][valgrind_release_cycle] | Distros

*Please add any tools that you can think of!*

Similarly, the time that it takes for a tool to be widely available in popular Linux distributions may be worthwhile to consider:

Distro | Release date | EOL | Tool + version | Release date | Time since release
------ | ------------ | --- | -------------- | ------------ | ------------------
Alpine 3.15 | Nov 2021 | Nov 2023 | gdb 11.1 | Sep 2021 | 1yr 11mth
Alpine 3.15 | Nov 2021 | Nov 2023 | llvm 12.0.1 | Jul 2021 | 2yr 2mth
Alpine 3.15 | Nov 2021 | Nov 2023 | valgrind 3.18.1 | Oct 2021 | 1yr 10mth
Alpine 3.18 | Aug 2023 | May 2025 | gdb 13.1 | Feb 2023 | 6mth
Alpine 3.18 | Aug 2023 | May 2025 | llvm 16.0.6 | Mar 2023 | 5mth
Alpine 3.18 | Aug 2023 | May 2025 | valgrind 3.21 | Apr 2023 | 4mth
ArchLinux | N/A | N/A | gdb 13.2 | May 2023 | 3mth
ArchLinux | N/A | N/A | llvm 15.0.7 | Jan 2023 | 7mth
ArchLinux | N/A | N/A | valgrind 3.21 | Apr 2023 | 4mth
CentOS Stream 9 | Dec 2021 | 2027 (est) | gdb 10.2 | Apr 2021 | 2yr 4mth
CentOS Stream 9 | Dec 2021 | 2027 (est) | llvm 16.0.6 | Mar 2023 | 5mth
CentOS Stream 9 | Dec 2021 | 2027 (est) | valgrind 3.21 | Apr 2023 | 4mth
Debian Stable 10 | Jul 2019 | Jun 2024 | gdb 8.2.1 | Dec 2018 | 4yr 8mth
Debian Stable 10 | Jul 2019 | Jun 2024 | llvm 11.0.1 | Jan 2021 | 2yr 7mth
Debian Stable 10 | Jul 2019 | Jun 2024 | valgrind 3.14 | Oct 2018 | 4yr 10mth
Debian Stable 12 | Jun 2023 | TBD | gdb 13.1 | Feb 2023 | 6mth
Debian Stable 12 | Jun 2023 | TBD | llvm 16.0.6 | Mar 2023 | 5mth
Debian Stable 12 | Jun 2023 | TBD | valgrind 3.19 | Apr 2022 | 4mth
Fedora 37 | Nov 2022 | Nov 2023 | gdb 13.2 | May 2023 | 3mth
Fedora 37 | Nov 2022 | Nov 2023 | llvm 15.0.7 | Jan 2023 | 7mth
Fedora 37 | Nov 2022 | Nov 2023 | valgrind 3.21 | Apr 2023 | 4mth
Fedora 38 | Apr 2023 | May 2024 | gdb 13.2 | May 2023 | 3mth
Fedora 38 | Apr 2023 | May 2024 | llvm 16.0.6 | Mar 2023 | 5mth
Fedora 38 | Apr 2023 | May 2024 | valgrind 3.21 | Apr 2023 | 4mth
Ubuntu 20.04 LTS | Apr 2020 | Apr 2025 | gdb 9.2 | May 2020 | 3yr 3mth
Ubuntu 20.04 LTS | Apr 2020 | Apr 2025 | llvm 12.0 | Jul 2021 | 2yr 2mth
Ubuntu 20.04 LTS | Apr 2020 | Apr 2025 | valgrind 3.15 | Apr 2019 | 4yr 4mth
Ubuntu 22.04 LTS | Apr 2022 | Apr 2032 | gdb 12.1 | May 2022 | 1yr 3mth
Ubuntu 22.04 LTS | Apr 2022 | Apr 2032 | llvm 15.0 | Sep 2022 | 11mth
Ubuntu 22.04 LTS | Apr 2022 | Apr 2032 | valgrind 3.18.1 | Oct 2021 | 1yr 10mth
Ubuntu 23.04 | Apr 2023 | Jan 2024 | gdb 13.1 | Feb 2023 | 6mth
Ubuntu 23.04 | Apr 2023 | Jan 2024 | llvm 15.0 | Sep 2022 | 10mth
Ubuntu 23.04 | Apr 2023 | Jan 2024 | valgrind 3.19 | Apr 2022 | 1yr 4mth

*Note:* When multiple versions were available in a distro, the most recent was chosen.

## Potential Solutions
There are various potential policies that the team could adopt:

- Create a standard timeline for how long to wait for a given change.
- Depending on the impact of the change, which tools break, etc.
- This is approximately what we've been doing now, just in an ad-hoc way.
- **Advantages**
- Minimizes disruption to users
- **Disadvantages**
- Significantly slows down development
- Add method(s) for users to opt-in to tool-breaking changes
- e.g. `-Zgdb-version=next`
- Would these flags ever be stablized? Should there be one flag for external-dependency-breaking changes or one per dependency? Do we still require support in external dependencies for a change to behind a flag like this (but don't require dependencies to have released it)?
- **Advantages**
- Allows development within rustc to proceed with some momentum
- **Disadvantages**
- Adds complexity to testing
- Distribute our own builds of dependent tools
- e.g. `rustup component add valgrind && rust-valgrind`
- **Advantages**
- Avoid the problem entirely - only support the versions we distribute, with our patches, can make changes as quickly as we like
- **Disadvantages**
- Complicates release process
- What if our patches never land upstream?

These aren't necessarily mutually exclusive.

## Discussion Topic Queue

- What about tools that are proprietary/internal-to-companies, but depend on our debuginfo/mangling/etc?

- Another facet that may be worth considering is "what environment is the tool normally used in?" For example, tooling that runs in production environments may be expected to evolve more slowly as upgrading prod is not as easy as upgrading developer workstations (probably).

- Another spin on "Add method(s) for users to opt-in to tool-breaking changes" is that allowing users to tell us what tools they plan to use allows us to make better choices. For instance, if know users are going to use gdb instead of lldb we might choose to generate slightly different debuginfo (or even if they are targeting a recent version of gdb vs a very old one).

- Basically same as the above (what environment): Can we separate this by external deps for developers of Rust vs external deps for use by users of programs written in Rust? I (Ben) would really like rustc to never use packages from my system and package everything itself, because of how often the debuginfo tests break on a rolling distro. But users of Rust programs will often expect that tools they use on all their C/C++ programs work on Rust. Or it would be very cool if they did.

- Rust is supported on distros not listed: Namely CentOS stream 8 and CentOS 7. The only option for distros so old as CentOS 7 (and possibly Ubuntu 20?) is to bring your own tools. Regardless of what we decide here, should we have any separate effort to support such use? i.e. make available a gdb that will work with Rust that users can bring to such a system, even if it is not packaged in rustup.

[gnu_release_cycle]: https://gcc.gnu.org/develop.html#timeline
[llvm_release_cycle]: https://llvm.org/docs/HowToReleaseLLVM.html#:~:text=Release%20Timeline,on%20feedback%20from%20the%20community.
[valgrind_release_cycle]: https://wiki.freebsd.org/Valgrind#:~:text=The%20devel%2Fvalgrind%20port%20follows,Packages%3A%20pkg%20install%20valgrind