* 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
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%)
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
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
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>
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes https://github.com/zed-industries/zed/issues/57073
Release Notes:
- Fixed running Zed on Ubuntu 20.04 installed via the installer by
bundling the required `libstdc++.so`.
Closes#51339
This should address issues with too new libstdc++.so on older/more
conservative distros such as RHEL9.
Release Notes:
- Relaxed requirement for libstdc++.so available on Linux distros.
Closes#45507
There have been 5+ PRs attempting to fix Linux desktop icon association
by adding `StartupWMClass` back to the `.desktop.in` template (#15763,
#20644, #23459, #33019, #37962), all closed because `StartupWMClass` is
an X11-specific key that GNOME happens to misuse on Wayland, and the
correct fix per the FreeDesktop spec is to name the `.desktop` file to
match the app's Wayland `app_id` / X11 `WM_CLASS`. Refer:
https://github.com/zed-industries/zed/issues/12707#issuecomment-2168742761
The root cause is that `bundle-linux` was never updated to produce the
correct filename in the tarball. The only consumers of the tarball's
desktop file are `install.sh` and manual extractors. So this fix is for
people who download the tarball and extract it without `install.sh`. The
docs already tell them to rename, but as @wcbing points out, not
everyone reads that carefully.
We are now making `bundle-linux` produce the correctly named desktop
file from the start.
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
One of the reasons we didn't spot that we were missing the telemetry env
vars for the production builds was that nightly (which was working) had
its own set of build steps. This re-uses those and pushes the env vars
down from the workflow to the job.
It also fixes nightly releases to upload all-in-one go so that all
platforms update in sync.
Closes#41655
Release Notes:
- N/A
I noticed we had some typos that were getting through CI, but it looks
like the new version of `typos` catches them. So I updated it and fixed
them.
Release Notes:
- N/A
- [x] Upload separate debug symbols for Linux binaries to DigitalOcean
- [x] Send raw offsets with panic report JSON on Linux
- [x] Update `symbolicate` script to handle Linux crashes
- [x] Demangle backtraces 🎉
- [x] Check that it works
- [x] Improve deduplication (?)
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
Similar to #20826 but keeps the Swift implementation. There were quite a
few changes in the `call` crate, and so that code now has two variants.
Closes#13714
Release Notes:
- Added preliminary Linux support for voice chat and viewing
screenshares.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Fixes shellcheck errors in script/*
Adds a couple trailing newlines.
Adds `script/shellcheck-scripts` and associated CI machinery.
Current set ultra-conservative, does not output warnings, only errors.
The install-linux script fails to build when the RUSTFLAGS environment
variable is not set. Bash attempts to expand an empty variable and fails
due to the prior set -u
Closes#17217
Release Notes:
- N/A
This is a first step towards allowing you to edit remote projects
directly over SSH. We'll start with a pretty bare-bones feature set, and
incrementally add further features.
### Todo
Distribution
* [x] Build nightly releases of `zed-remote-server` binaries
* [x] linux (arm + x86)
* [x] mac (arm + x86)
* [x] Build stable + preview releases of `zed-remote-server`
* [x] download and cache remote server binaries as needed when opening
ssh project
* [x] ensure server has the latest version of the binary
Auth
* [x] allow specifying password at the command line
* [x] auth via ssh keys
* [x] UI password prompt
Features
* [x] upload remote server binary to server automatically
* [x] opening directories
* [x] tracking file system updates
* [x] opening, editing, saving buffers
* [ ] file operations (rename, delete, create)
* [ ] git diffs
* [ ] project search
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Turns out that the existing CI step for Nightly did create the licenses
and they have been baked into X86 builds ever since, because our
builders are stateful.
On ARM machines, the licenses wouldn't exist in the binary because we
called `script/generate-licenses` too late in `scripts/bundle-linux`,
after the binary had been created.
This removes the duplication and generates the licenses once, before the
binary is created.
Fixes#14302.
Release Notes:
- Fixed "View Dependency Licenses" (or `zed: open licenses`) crashing on
Linux ARM machines.
([#14302](https://github.com/zed-industries/zed/issues/14302)
https://doc.rust-lang.org/cargo/reference/environment-variables.html
Some people (myself included) set this variable to have a single
directory to clean up (or whatever reason one might have for having a
single `target` directory). This changes the linux scripts to respect
that
Release Notes:
- N/A
This ensures that linux panics still contain symbol names. It also
allows us to profile Zed on linux with `perf` and get symbol names.
Release Notes:
- N/A
> * There are a couple of other `zed` binaries that may be present on
linux systems
([1](https://openzfs.github.io/openzfs-docs/man/v2.2/8/zed.8.html),
[2](https://zed.brimdata.io/docs/commands/zed)). If you want to rename
our CLI
binary because of these issues, we suggest `zedit`, `zeditor`, or
`zed-cli`.
Due to aformentioned issue don't hardcode the executable name in the
.desktop file so envsubst can change it in accordance with the
distributor's requirement.
Resolves#12290.
Release Notes:
- N/A
Fixes#12585
This changes the expectations for installed binaries on linux based on
work
that @jirutka has done for Alpine.
In particular, we now put the cli in place as `bin/zed` and the zed
binary as
`libexec/zed-editor`, and assume that packagers do the same.
cc @someone13574
Release notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
ping #6687
This is the third iteration of this PR ([v2
here](https://github.com/zed-industries/zed/pull/11949)) and uses a
different approach to the first two (the process wrapper lib was a
maintainability nightmare). While the first two attempted to spawn the
necessary processes using flatpak-spawn and host-spawn from the app
inside the sandbox, this version first spawns the cli binary which then
restart's itself *outside* of the sandbox using flatpak-spawn. The
restarted cli process than can call the bundled app binary normally,
with no need for flatpak-spawn because it is already outside of the
sandbox. This is done instead of keeping the cli in the sandbox because
ipc becomes very difficult and broken when trying to do it across the
sandbox.
Gnome software (example using nightly channel and release notes
generated using the script):
<img
src="https://github.com/zed-industries/zed/assets/81528246/6391d217-0f44-4638-9569-88c46e5fc4ba"
width="600"/>
TODO in this PR:
- [x] Bundle libs.
- [x] Cleanup release note converter.
Future work:
- [ ] Auto-update dialog
- [ ] Flatpak auto-update (complete 'Auto-update dialog' first)
- [ ] Experimental
[bundle](https://docs.flatpak.org/en/latest/single-file-bundles.html)
releases for feedback (?).
*(?) = Maybe / Request for feedback*
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
yenru0
Kirill Bulatov