11 KiB
Building Zed for Linux
Repository
Clone down the Zed repository.
Dependencies
-
Install rustup
-
Install the necessary system libraries:
script/linux
If you prefer to install the system libraries manually, you can find the list of required packages in the
script/linux
file.
Backend dependencies
This section is still in development. The instructions are not yet complete.
If you are developing collaborative features of Zed, you'll need to install the dependencies of zed's collab
server:
Alternatively, if you have Docker installed you can bring up all the collab
dependencies using Docker Compose:
docker compose up -d
Building from source
Once the dependencies are installed, you can build Zed using Cargo.
For a debug build of the editor:
cargo run
And to run the tests:
cargo test --workspace
In release mode, the primary user interface is the cli
crate. You can run it in development with:
cargo run -p cli
Installing a development build
You can install a local build on your machine with:
./script/install-linux
This will build zed and the cli in release mode and make them available at ~/.local/bin/zed
, installing .desktop files to ~/.local/share
.
Note
: If you encounter linker errors similar to the following:
error: linking with `cc` failed: exit status: 1 ... = note: /usr/bin/ld: /tmp/rustcISMaod/libaws_lc_sys-79f08eb6d32e546e.rlib(f8e4fd781484bd36-bcm.o): in function `aws_lc_0_25_0_handle_cpu_env': /aws-lc/crypto/fipsmodule/cpucap/cpu_intel.c:(.text.aws_lc_0_25_0_handle_cpu_env+0x63): undefined reference to `__isoc23_sscanf' /usr/bin/ld: /tmp/rustcISMaod/libaws_lc_sys-79f08eb6d32e546e.rlib(f8e4fd781484bd36-bcm.o): in function `pkey_rsa_ctrl_str': /aws-lc/crypto/fipsmodule/evp/p_rsa.c:741:(.text.pkey_rsa_ctrl_str+0x20d): undefined reference to `__isoc23_strtol' /usr/bin/ld: /aws-lc/crypto/fipsmodule/evp/p_rsa.c:752:(.text.pkey_rsa_ctrl_str+0x258): 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
Cause: this is caused by known bugs in aws-lc-rs(doesn't support GCC >= 14): FIPS fails to build with GCC >= 14 & GCC-14 - build failure for FIPS module
You can refer to linux: Linker error for remote_server when using script/install-linux for more information.
Workarounds: Set the remote server target to
x86_64-unknown-linux-gnu
like soexport REMOTE_SERVER_TARGET=x86_64-unknown-linux-gnu; script/install-linux
Wayland & X11
Zed supports both X11 and Wayland. By default, we pick whichever we can find at runtime. If you're on Wayland and want to run in X11 mode, use the environment variable WAYLAND_DISPLAY=''
.
Notes for packaging Zed
Thank you for taking on the task of packaging Zed!
Technical requirements
Zed has two main binaries:
- You will need to build
crates/cli
and make its binary available in$PATH
with the namezed
. - You will need to build
crates/zed
and put it at$PATH/to/cli/../../libexec/zed-editor
. For example, if you are going to put the cli at~/.local/bin/zed
put zed at~/.local/libexec/zed-editor
. As some linux distributions (notably Arch) discourage the use oflibexec
, you can also put this binary at$PATH/to/cli/../../lib/zed/zed-editor
(e.g.~/.local/lib/zed/zed-editor
) instead. - If you are going to provide a
.desktop
file you can find a template incrates/zed/resources/zed.desktop.in
, and useenvsubst
to populate it with the values required. This file should also be renamed to$APP_ID.desktop
so that the file follows the FreeDesktop standards. - You will need to ensure that the necessary libraries are installed. You can get the current list by inspecting the built binary on your system.
- For an example of a complete build script, see script/bundle-linux.
- You can disable Zed's auto updates and provide instructions for users who try to update Zed manually by building (or running) Zed with the environment variable
ZED_UPDATE_EXPLANATION
. For example:ZED_UPDATE_EXPLANATION="Please use flatpak to update zed."
. - Make sure to update the contents of the
crates/zed/RELEASE_CHANNEL
file to 'nightly', 'preview', or 'stable', with no newline. This will cause Zed to use the credentials manager to remember a user's login.
Other things to note
At Zed, our priority has been to move fast and bring the latest technology to our users. We've long been frustrated at having software that is slow, out of date, or hard to configure, and so we've built our editor to those tastes.
However, we realize that many distros have other priorities. We want to work with everyone to bring Zed to their favorite platforms. But there is a long way to go:
- Zed is a fast-moving early-phase project. We typically release 2-3 builds per week to fix user-reported issues and release major features.
- There are a couple of other
zed
binaries that may be present on Linux systems (1, 2). If you want to rename our CLI binary because of these issues, we suggestzedit
,zeditor
, orzed-cli
. - Zed automatically installs the correct version of common developer tools in the same way as rustup/rbenv/pyenv, etc. We understand this is contentious, see here.
- We allow users to install extensions locally and from zed-industries/extensions. These extensions may install further tooling as needed, such as language servers. In the long run, we would like to make this safer, see here.
- Zed connects to several online services by default (AI, telemetry, collaboration). AI and our telemetry can be disabled by your users with their zed settings or by patching our default settings file.
- As a result of the above issues, zed currently does not play nice with sandboxes, see here
Flatpak
Zed's current Flatpak integration exits the sandbox on startup. Workflows that rely on Flatpak's sandboxing may not work as expected.
To build & install the Flatpak package locally follow the steps below:
- Install Flatpak for your distribution as outlined here.
- Run the
script/flatpak/deps
script to install the required dependencies. - Run
script/flatpak/bundle-flatpak
. - Now the package has been installed and has a bundle available at
target/release/{app-id}.flatpak
.
Memory profiling
heaptrack
is quite useful for diagnosing memory leaks. To install it:
$ sudo apt install heaptrack heaptrack-gui
$ cargo install cargo-heaptrack
Then, to build and run Zed with the profiler attached:
$ cargo heaptrack -b zed
When this zed instance is exited, terminal output will include a command to run heaptrack_interpret
to convert the *.raw.zst
profile to a *.zst
file which can be passed to heaptrack_gui
for viewing.
Troubleshooting
Cargo errors claiming that a dependency is using unstable features
Try cargo clean
and cargo build
.
Vulkan/GPU issues
If Zed crashes at runtime due to GPU or vulkan issues, you can try running vkcube (usually available as part of the vulkaninfo
package on various distributions) to try to troubleshoot where the issue is coming from. Try running in both X11 and wayland modes by running vkcube -m [x11|wayland]
. Some versions of vkcube
use vkcube
to run in X11 and vkcube-wayland
to run in wayland.
If you have multiple GPUs, you can also try running Zed on a different one to figure out where the issue comes from. You can do so a couple different ways:
Option A: with vkdevicechooser)
Or Option B: By using the ZED_DEVICE_ID={device_id}
environment variable to specify the device ID.
You can obtain the device ID of your GPU by running lspci -nn | grep VGA
which will output each GPU on one line like:
08:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484] (rev a1)
where the device ID here is 2484
. This value is in hexadecimal, so to force Zed to use this specific GPU you would set the environment variable like so:
ZED_DEVICE_ID=0x2484
Make sure to export the variable if you choose to define it globally in a .bashrc
or similar
Reporting Vulkan/GPU issues
When reporting issues where Zed fails to start due to graphics initialization errors on GitHub, it can be impossible to run the zed: copy system specs into clipboard
command like we instruct you to in our issue template. We provide an alternative way to collect the system specs specifically for this situation.
Passing the --system-specs
flag to Zed like
zed --system-specs
will print the system specs to the terminal like so. It is strongly recommended to copy the output verbatim into the issue on GitHub, as it uses markdown formatting to ensure the output is readable.
Additionally, it is extremely beneficial to provide the contents of your Zed log when reporting such issues. The log is usually stored at ~/.local/share/zed/logs/Zed.log
. The recommended process for producing a helpful log file is as follows:
truncate -s 0 ~/.local/share/zed/logs/Zed.log # Clear the log file
ZED_LOG=blade_graphics=info zed .
cat ~/.local/share/zed/logs/Zed.log
# copy the output
Or, if you have the Zed cli setup, you can do
ZED_LOG=blade_graphics=info /path/to/zed/cli --foreground .
# copy the output
It is also highly recommended when pasting the log into a github issue, to do so with the following template:
Note
: The whitespace in the template is important, and will cause incorrect formatting if not preserved.
<details><summary>Zed Log</summary>
```
{zed log contents}
```
</details>
This will cause the logs to be collapsed by default, making it easier to read the issue.