script/bundle-mac now downloads the pinned pdfium-mac tarball from
bblanchon/pdfium-binaries into Zed.app/Contents/Frameworks, matching
what bundle-linux and bundle-windows.ps1 already do, so the bundled
pdf_viewer no longer falls back to synthetic rendering on macOS. The
runtime loader probes ../Frameworks next to the executable.
Sweep every user-visible product string to Gwen: app menus (Quit,
Hide, Gwen Repository), feedback links (repo/issues now point at
github.com/kk376/zed, email to yenru@yrkaierx.com), move-to-Applications
and update dialogs, provider and settings copy, CLI help, installer and
desktop/flatpak/snap/plist metadata.
Rename user-facing settings values with back-compat aliases: base_keymap
"Gwen" (accepts "Zed"), fonts ".GwenMono"/".GwenSans" (accept
".ZedMono"/".ZedSans"), icon theme "Gwen (Default)". Fix F10
app-menu keymap arguments to "Gwen" and align the Windows installer
AppMutex with release_channel::app_identifier(). Internal identifiers,
wire protocol names, upstream service URLs and legal attribution are
intentionally kept.
The icon rename removed app-icon-*.png but left the cargo-bundle
metadata referencing them, so bundle-mac could not produce an app
bundle. Point every channel at app-icon-gwen*.png, align bundle
identifiers and names with release_channel (com.yrkaierx.Gwen*), and
rename the DMG artifact and volume to Gwen.
# Objective
- This PR enables users to switch between unified/split diff views when
comparing buffers.
- Fixes#64419 .
## Solution
- The unified/split toggle (`DiffStyleControls`) is normally surfaced
automatically by `BufferSearchBar`, which detects any active item
exposing a `SplittableEditor`. That auto-detection is gated to
multi-buffer views, since it's paired with an expand/collapse-all-hunks
control that only makes sense across multiple files. `FileDiffView`
(used by `zed --diff <old> <new>`) is a singleton buffer, so it's
intentionally excluded from that generic path.
- Git's own single-file diff view,
[`SoloDiffView`](https://github.com/zed-industries/zed/blob/f2e33599724432f329f9e23b353a8fb28cd6ece3/crates/git_ui/src/solo_diff_view.rs#L52),
hits the same limitation and works around it with a small, dedicated
`ToolbarItemView` (`SoloDiffStyleToolbar`) that renders
`DiffStyleControls` directly, independent of `BufferSearchBar`.
- This PR follows the same pattern: a new `FileDiffStyleToolbar` (in
`git_ui_core::file_diff_view`) activates whenever a `FileDiffView` is
the focused pane item, and renders just the unified/split toggle, no
expand/collapse or file-status controls, since neither concept applies
to a plain two-file diff. It's registered in `initialize_pane` alongside
the existing git toolbars.
## Testing
- Did you test these changes? If so, how?
Ran `cargo test -p git_ui_core`, all passed. I've also attached the
results of manual testing in the Showcase section below.
- Are there any parts that need more testing?
I think more tests can be added.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Adds a unified/split toggle to the diff view opened via `zed --diff
<old> <new>`, matching the toggle already available in git's diff views.
<details>
<summary>Click to view before/after</summary>
**Before**:
<img width="1920" height="1080" alt="screenshot_20260921_020610"
src="https://github.com/user-attachments/assets/92cbcf75-0cac-4555-8d2d-ce927064515f"
/>
**After**:
<img width="1920" height="1080" alt="screenshot_20260921_020355"
src="https://github.com/user-attachments/assets/56f9ebc6-11df-41cc-a44d-99bfa8caa130"
/>
</details>
---
Release Notes:
- Added a unified/split toggle to the diff view opened via `zed --diff
<old> <new>` command.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
* Preserve bundle compiler flags commit commit is a follow-up to
https://github.com/zed-industries/zed/pull/63432
Linux bundling script had custom `RUSTFLAGS` set which eradicated prior
config.
Moved all flags into `.cargo/bundle-config.toml` instead.
* Trim audio features and compress resources commit removes unused
`rodio` features and enables resource compression
The win from the latter seems not that large, so can revert if needed,
but seemed very easy to enable.
With compiler wrappers disabled, `cargo clean --target-dir
target/binary-size-split-build` and `cargo build --locked -p zed`:
Before: 135.6s wall, 1569.8s CPU, zed binary 1175563800 bytes
After: 130.5s wall (-3.8%), 1488.7s CPU (-5.2%), zed binary 1171527064
bytes (-0.3%, -4.0MB)
With `ZED_BUNDLE=true CXXFLAGS=-stdlib=libc++` and `cargo --config
.cargo/bundle-config.toml build --locked --release -p zed -p cli
--target aarch64-apple-darwin`:
Before: 369.4s wall, 3861.6s CPU, zed binary 381662328 bytes
After: 369.4s wall (+0.01%), 3866.1s CPU (+0.1%), zed binary 377836968
bytes (-1.0%, -3.8MB)
Release Notes:
- N/A
This PR cleans up the repository root a bit, moving some of the less
relevant config files into the `.config` folder and removing unused
ones.
Release Notes:
- N/A
Release notes are the sole information users have about what could
either have improved or have been broken for them. Omitting release
notes is one thing, but not writing any or having empty ones helps
nobody - users get no context on what could cause issues they were
seeing nor do they know about potential improvements, triagers cannot
easily find the PR that could have introduced the bug either.
Thus, this PR now makes it so that danger actually requires one to write
release notes. Empty release notes or the placeholder will no longer be
accepted.
Release Notes:
- N/A
# Objective
Bumps `wasi-sdk` to v34 that is based on LLVM 23.1 which includes [a
compile time and memory usage
fix](https://github.com/llvm/llvm-project/pull/181755) for tree-sitter
grammars. It speeds up every grammar's compile time and reduces compile
memory usage unlocking big grammars that were impossible to compile
before to be submitted to Zed extensions.
Drive-by added additional wasi-sdk targets for the rest of the supported
architectures (by wasi-sdk), if riscv is unwanted I can remove it but it
should not create any problems (I think).
Also noticed the `download-wasi-sdk` script had `OS=mingw` which wasn't
even in the artifact name on v25.
## Testing
Compiled, ran and compiled my [big
grammar](https://github.com/usagi-coffee/tree-sitter-abl) on it, that
wouldn't compile at all pre-llvm 23.
## Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
---
Release Notes:
- Fixed compiling dev extensions with big Tree-sitter grammars.
- Fixed compiling dev extensions on Windows ARM64.
- Added wasi-sdk installation invalidation.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
The particular edge case that is covered here is closing a community PR,
then labeling it with an `area:`, and _then_ reopening it.
Release Notes:
- N/A
It's been fun for a while to have the same function calling GitHub API
in every single script, but we're going to have fun in different ways
now.
This one's for you, @MrSubidubi! 🥂
## Testing
I've ran the things that had `--dry-run` locally and nothing blew up,
but the ultimate smoke test will be carried out in production.
---
Release Notes:
- N/A
We already had the PR's upvotes (all the positive reactions,
deduplicated by user); this commit adds the issue-closed-by-the-PR's
upvotes (deduplicated against the PR's upvoters too). The code got even
uglier because I'm trying to avoid extra API calls.
Release Notes:
- N/A
Not sure if this PR is 100% good, since it removes symbols from local
traces, leaving addresses only — but this what Windows seem to do
already, and we have those symbols on Sentry to restore from, which were
needed to normally read Linux perf traces already (see `perf.zip` in
https://github.com/zed-industries/zed/issues/59689#issuecomment-5452720248)
On the upside, uncompressed binaries' are now ~100MB less, which is a
lot — hence decided to open the PR for the review
-------------------
Strips debug info and local symbols from shipped macOS and Linux
binaries, matching what Windows already does with PDBs: `bundle-mac` now
always runs `dsymutil` before a new `strip -x` step, and `bundle-linux`
adds `--discard-all` plus `zed.dbg`/`remote_server.dbg` extraction via
`--only-keep-debug`.
Sentry uploads are unchanged and precede stripping.
The macOS binary UUID and the GNU build id survive stripping, so
user-provided traces stay recoverable without rebuilding at the
reporter's commit: `sample` output resolves via `atos` against the
archived `zed.dwarf`, and `perf.data` via `perf buildid-cache` against
the Sentry-archived binary.
zed binary:
macOS (2026-08-29 nightly): 420478976 -> 316503984 bytes (-24.7%,
-104.0MB)
Linux (v1.17.2 aarch64): 439417448 -> 336967256 bytes (-23.3%, -102.5MB)
Downloads shrink far less, symbols compress ~7:1: the macOS DMG loses
only ~15MB.
Release Notes:
- Improved installed size on macOS and Linux by stripping debug symbols
from release binaries (roughly -25%)
Improves merge-conflict loading by resolving ordered conflict anchors
with a single excerpt sweep instead of restarting the excerpt scan four
times per conflict.
The pull request also adds `script/generate-merge-conflict-benchmark`,
which creates validated small, medium, or severe repositories with real
unresolved Git merges.
On the severe workload (128 files × 256 conflicts), anchor conversion
decreased from 483.5 ms to 5.9 ms, saving about 478 ms, or roughly 5% of
the total refresh.
Closes
https://linear.app/zed-industries/issue/FR-174/improve-git-panel-performance-for-large-merge-conflicts
## Testing
- `cargo test -p multi_buffer
test_ordered_buffer_anchor_ranges_to_anchor_ranges`
- `cargo test -p git_ui conflict`
- `./script/clippy -p multi_buffer -p git_ui`
- Generated and validated the small synthetic merge-conflict workload
Release Notes:
- Improved performance when opening large merge conflicts
* ensures The Rule cannot be accidentall removed
* fixes the perf command example to capture call graphs, to avoid
round-trips like
https://github.com/zed-industries/zed/issues/59689#issuecomment-5453623044
(samples without call graphs are not quite usable for investigating bugs
like these)
Release Notes:
- N/A
Cargo joins `build.rustflags` across config sources, so the base
`symbol-mangling-version=v0` and `tokio_unstable` flags still apply
after the newly added config.
With sccache disabled, `cargo build --release -p zed` on macOS:
Before: zed binary 420677880 bytes
After: zed binary 375109048 bytes (-10.8%, -45.6MB)
After `strip -x` of both
(https://github.com/zed-industries/zed/pull/63429):
313879024 -> 307727432 bytes (-2.0%, -6.2MB)
The rest of the delta is the smaller symbol table. `drop_glue`
instantiations: 101778 -> 65041.
Release Notes:
- N/A
- Notify the author when their PR has been in draft state with no new
commits for three weeks
- Close the draft PRs that didn't get updated after one more week
- Re-try the cla-bot check on PRs that are still unsigned after a week
- Close the PRs that are still unsigned after the re-try
## Testing
It works on my machine™
```
python script/github-pr-cleanup.py --dry-run
Checking 713 open pull requests
Dry-run mode: no comments or closures will be made
PR #60885: asking the CLA bot to check again
Would comment on PR #60885:
@cla-bot check
PR #61625: asking the CLA bot to check again
Would comment on PR #61625:
@cla-bot check
PR #57239: warning about a stale draft
Would comment on PR #57239:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #57241: warning about a stale draft
Would comment on PR #57241:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61461: warning about a stale draft
Would comment on PR #61461:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61722: warning about a stale draft
Would comment on PR #61722:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61808: warning about a stale draft
Would comment on PR #61808:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61809: warning about a stale draft
Would comment on PR #61809:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
Cleanup complete: 0 unsigned PR closures, 6 draft warnings, 0 draft closures
```
Release Notes:
- N/A
Bundled GLib shadowed the system libraries for host plugins dlopen'd
into the process, like PipeWire's videoconvert on 1.6+, which would
break Wayland screen sharing on newer distros. This PR makes Zed rely on
system GLib instead, since the bundled version pulls from whatever is in
CI (presently Ubuntu 20.04).
Release Notes:
- Removed GLib libraries from Linux release bundle, which could conflict
with system plugins
Release Notes:
- Fixed broken links in the installer Terms of Service dialog (#62677).
---
### Description
Closes#62677
In `script/terms/terms.rtf` and `legal/terms.md` (as well as
`legal/privacy-policy.md` and `legal/third-party-terms.md`), relative
URLs like `/privacy-policy` and `/acceptable-use-policies` caused error
-50 ("The application can't be opened") when clicked from installer
dialogs (such as the macOS installer).
This PR updates the relative URLs to absolute `https://zed.dev` URLs so
they open properly in the browser.
Label | Description
-- | --
area:integrations/git/panel | Feedback for the Git panel UI and
behavior.
area:gpui/graphics/wgpu | Feedback for GPUI's WGPU graphics backend,
including initialization and rendering.
area:breadcrumbs | Feedback for editor path and symbol breadcrumbs.
area:title bar | Issues suitable for title bar.
area:ai/agent thread/checkpoints | Feedback for Agent checkpoint
creation, comparison, restoration, and related Git behavior.
area:ai/agent thread/tools | Feedback for built-in Agent tools,
including execution, permissions, inputs, and outputs.
Release Notes:
- N/A
Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.
Release Notes:
- N/A
# Objective
Prevent successful installations on 32-bit Linux architectures where the
`zed` binary will **fail to execute** post-installation. Rather, fail at
installation time with a proper verdict.
`script/install.sh` maps `uname -m` onto the two architectures Zed
publishes builds for. Two of the matchers named 32-bit userlands and
mapped them onto a 64-bit tarball:
- `linux-armhf` mapped to `aarch64`
- `linux-i686*` mapped to `x86_64`
Neither can execute the binary it selected. Tested on i386 Debian Trixie
container: the installer downloaded, unpacked, symlinked and reported
success, and the failure surfaced later as an exec error -- see
[Showcase](##showcase).
Thus the installer's correct behavior would be to reject the 32-bit
architecture and terminate with an "unsupported" verdict.
## Solution
Remove the case-statement-based mapping of `linux-armhf` to `aarch64`,
and of `linux-i686*` to `x86_64`.
## Testing
Tested in isolation, simulating supported and unsupported platforms, and
supported and unsupported architectures:
| Platform | `uname -m` | Outcome |
| --- | --- | --- |
| Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created
|
| Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no
case handles plain i386 anyway |
| Linux | `i686` | ❌ Unsupported — same reason |
| Linux | `aarch64` | ✅ Installed — resolves to `aarch64` |
| Linux | `arm64` | ✅ Installed — resolves to `aarch64` |
| Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case |
| Linux | `riscv64` | ❌ Unsupported |
| Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real
`/Applications/Zed.app`, symlink created; |
| Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real
`/Applications/Zed.app`, symlink created |
| Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit |
| FreeBSD | `x86_64` | ❌ Unsupported platform - expected |
This is all correct behavior. Successful installations are expected to
work. Unsupported architectures are detected and rejected as unsupported
during installation.
## Showcase
```plaintext
~# file /usr/bin/dash # a sample executable showing the 32-bit arch
/usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped
~# file .local/zed.app/bin/zed
.local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped
~# .local/zed.app/bin/zed
bash: .local/zed.app/bin/zed: cannot execute: required file not found
# It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is
# a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with:
# `Exec format error`.
```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Locally conducted tests cover the new/changed behavior
---
Release Notes:
- N/A
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/24880
# Objective
"Assisted/analysed by AI"
> The remote_server musl build failed with undefined references to
__isoc23_sscanf and __isoc23_strtol from aws-lc-sys because the default
C compiler used glibc headers while linking against musl libc. Setting
CC_<target>=musl-gcc ensures C dependencies compile with musl headers.
I have tested the fix, and it seems to have fixed the compilation issue
I faced on Fedora 44, without resorting to the [hack noted in
docs](https://zed.dev/docs/development/linux#installing-a-development-build).
Initially reported in this
[issue](https://github.com/zed-industries/zed/issues/24880).
I'd want someone with expertise in the domain to take a look at this
fix, as from what I understand, the process in the doc is a hacky
workaround.
## Solution
Setting CC_<target>=musl-gcc ensures C dependencies compile with musl
headers.
## Testing
- Did you test these changes? If so, how?
<details><summary>Here's my steps to repro:</summary>
1. install [toolbox](https://github.com/containers/toolbox) (or
podman-toolbox)
(I used toolbox as it's easy to reuse the cloned repo, as the whole home
dir is mounted in the devcontainer)
Used the main branch - commit c3027f441c
2. toolbox create -d fedora -r 44
3. toolbox enter fedora-toolbox-44
4. then run the `scripts/linux` script to install prereqs
5. try compiling remote-server using the commands in
`scripts/install-linux` (I just ran the script wholly)
LDD version:
```
⬢[root@toolbox zed]# ldd --version
ldd (GNU libc) 2.43
```
GCC/MUSL versions:
```
musl-gcc : 1.2.5
gcc : 16.1.1
```
Error:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/rcrt1.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crti.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtbeginS.o"
"<747 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/{libzstd_sys-5c3eb6739555ecf4,libtree_sitter_json-ad90c8af7e8a3750,libtree_sitter-f91a92b688e12e56,libwasmtime-decd3377028506ce,libaws_lc_sys-a051f708b6dafc2a,libring-fcc1b43e3092bc93,libpsm-d967f50c6f2b67a4}.rlib"
"-lunwind" "-lc"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-*.rlib"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/raw-dylibs"
"-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack"
"-nostartfiles" "-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/psm-dc603221f407eabc/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-28f7b87c1db3fab9/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/wasmtime-f0bb0950e09a7352/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/aws-lc-sys-2a7ca8eafafe18fa/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/ring-d7857a166bac60a6/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/zstd-sys-0e04609af7157148/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-json-b1e2eeaba7bbb519/out"
"-L"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained"
"-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib" "-o"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/remote_server-3782b255c59d4e14"
"-Wl,--gc-sections" "-static-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1"
"-nodefaultlibs" "-Wl,--disable-new-dtags,-rpath,$ORIGIN/../lib"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtendS.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtn.o"
= note: some arguments are omitted. use `--verbose` to show all linker
arguments
= note: /usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `aws_lc_0_40_0_handle_cpu_env':
/aws-lc/crypto/fipsmodule/cpucap/cpu_intel.c:(.text.aws_lc_0_40_0_handle_cpu_env+0x63):
undefined reference to `__isoc23_sscanf'
/usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `pkey_rsa_ctrl_str':
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:692:(.text.pkey_rsa_ctrl_str+0x222):
undefined reference to `__isoc23_strtol'
/usr/bin/ld.bfd:
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:703:(.text.pkey_rsa_ctrl_str+0x261):
undefined reference to `__isoc23_strtol'
collect2: error: ld returned 1 exit status
= note: some `extern` functions couldn't be found; some native libraries
may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native
libraries to link with Cargo (see
https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)
error: could not compile `remote_server` (bin "remote_server") due to 1
previous error
```
</details>
- Are there any parts that need more testing? -- Maybe
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? -- Steps listed above
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test? -- Fedora 44
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- Fixed musl error when building remote server from source for the
default musl triple on Linux
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
`priority:*` labels in the github repository are becoming `severity:*`,
and `frequency:*` — `reach:*`. This commit will update the slack
notifications for the first responders accordingly.
Also, delete the github-label-issues-to-triage.py one-off script, which
worked with the old label names and is by now too distant in the past to
be useful as reference or anything.
Release Notes:
- N/A
## Summary
- Upgrade sccache from 0.10.0 to 0.16.0 on macOS, Linux, and Windows CI
runners.
- Normalize the GitHub workspace with `SCCACHE_BASEDIRS` so identical
builds can reuse cache entries across checkout roots.
- Validate the cached binary version and stop an older server before
replacing it, including on Windows where a running executable cannot be
overwritten.
## Why
The setup scripts configured `SCCACHE_BASEDIR`, which sccache did not
use for cache-key path normalization. Absolute checkout paths therefore
remained part of cache keys and reduced reuse between CI workspaces.
sccache 0.16.0 supports `SCCACHE_BASEDIRS` and includes the Windows
path-normalization fix needed for the Windows runner.
## Validation
- `bash -n script/setup-sccache`
- `git diff --check`
- Upgraded a live local sccache 0.15.0 server to 0.16.0 through the
setup script.
- Compiled identical C sources from two checkout roots and observed one
cache miss followed by one cache hit.
- Confirmed that every release asset referenced by the setup scripts
exists for the supported CI runner targets.
Release Notes:
- N/A
script/linux tried to install dev-util/cmake, which is not the correct
package name, so the script fails. Changing it to dev-build/cmake fixes
this.
Release Notes:
- N/A
yenru0
