Bundle linux deps

[ConradIrwin]

Inlcude linux deps in the bundle

Release Notes:

• N/A

[jansol]

I fear that this will only make it more difficult to diagnose dependency problems -- by papering over direct dependencies you change the errors that users will see to refer to the dependencies' dependencies.

This is also bound to lead to fun situations when e.g. Ubuntu pushes an ABI change to said indirect dependencies (they spent a big part of last month doing exactly that ahead of the 24.04 LTS release).

And occasionally you can expect some even more bizarre failure modes: libxkbcommon0 for example is a direct dependency and on ubuntu it depends on xkb-data on ubuntu. I don't imagine libxkbcommon.so copes well with missing its data files...

[ConradIrwin]

@jansol I may be wrong, but I think ldd accounts for indirect dependencies, and so we should have everything needed to boot zed included here. Do you have a setup where this is not working?

From my early conversations with people trying to use remote development, there are a number who need zed to work without sudo access, and I think this is the best way to support that (though I am open to other ideas if you have any).

It seems like the linker will continue to default to the system libraries if you have them installed, so this takes some % of users from "can't run zed at all" to "zed works, but we might find more problems later" :D.

[jansol]

Hmm looks like it does, I might remember that wrong then. It does however not see libraries that are loaded with dlopen, such as libvulkan1.so.

IIRC The linker goes in order LD_PRELOAD > executable directory > LD_LIBRARY_PATH > paths specified in ldconfig.

[ConradIrwin]

Thanks for the pointer. @kvark are there other libraries like vulkan that we need to bundle to make zed run without sudo?

[ConradIrwin]

I'm going to merge this as is so I can test the bundling/auto-updating aspects of this.

As the primary use-case right now is remote development, I don't expect to hit the missing vulkan libraries; but we can/should probably add them too.

[steev]

This doesn't seem to be correct - when I run it here, it errors out because target/debug/Zed doesn't exist - I'm assuming because I haven't run the cargo b manually; if you only run ./script/generate-license && ./script/bundle-linux it now fails.

The bundle script runs cargo b --release so the bundle script uses what it builds in target/$ARCH/release - e.g. on my system which happens to be arm64, I'm getting target/aarch64-unknown-linux-gnu/release/Zed

[ConradIrwin]

Sorry about that, fix here: #11783

[steev]

Confirming that it works, thanks for the quick fix!