Visual Studio Code Live Share does not function (missing libstdc++)

[kliu128]

Issue description

Visual Studio Code downloads a prebuilt exe to .vscode and tries to run it, but it errors with:

[Client.Agent E] Agent failed with error: Error: spawn /home/kevin/.vscode/extensions/ms-vsliveshare.vsliveshare-0.3.198/dotnet_modules/vsls-agent ENOENT

ldd output:

ldd vsls-agent
        linux-vdso.so.1 (0x00007ffd9dda6000)
        libdl.so.2 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib/libdl.so.2 (0x00007f335c233000)
        libpthread.so.0 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib/libpthread.so.0 (0x00007f335c014000)
        libstdc++.so.6 => not found
        libm.so.6 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib/libm.so.6 (0x00007f335bc7f000)
        libgcc_s.so.1 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib/libgcc_s.so.1 (0x00007f335ba69000)
        libc.so.6 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib/libc.so.6 (0x00007f335b6b5000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/27x7pinqdsl9f3rpbm8bsszd9fhwq266-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f335c437000)

Steps to reproduce

Install visual studio code and add the Live Share extension. Wait for it to download and error out.

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

 - system: `"x86_64-linux"`
 - host os: `Linux 4.16.11, NixOS, 18.09.git.c8c4053 (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.0.2`
 - channels(root): `""`
 - nixpkgs: `/etc/nixos/nixpkgs`

[b333z]

Wrote a bash script to patch the ext with a view to get a better understanding of how nixos hangs together.

Was hoping to get it to a derivation but times short, so here's the script in case anyone's up for a workaround (excuse sledgehammer rpath):

https://gist.github.com/b333z/5fb902161685c5141bbc91b39a152831#file-vsls

So you'd install the extension, run the script, still get the missing deps vscode notification on launch but seems ok after hitting cancel on that...

(would need to be re-ran each time ext updates...)

(updated: needed to patch more exe's as broken debugging)
(updated: needed openssl.out since nixos upgrade)

[kliu128]

Perhaps this could be run as a pre-start script before starting VSCode somehow? Not sure if it offers hooks on extension updates...

[phryneas]

I've started to create a package out of this (thanks for the great starting point @b333z ):
https://gist.github.com/phryneas/641ed9a316ff5166a30128575217dd0a

So far, I can log in and share, but my other PC can't join the session. Not sure if that is a problem with the extension or my network though. (The extension wants to write to it's directory and of course that's read-only)
So, if someone wants to experiment with it and has some ideas on how to make it work better, I'd be happy about feedback :)

To use it, install it into your user profile and symlink ~/.nix-profile/share/vscode/extensions/ms-vsliveshare.vsliveshare/ into your ~/.vscode/extensions folder.

Be warned though: I've moved a few paths where the extension would store data to /tmp - for now.

[ottidmes]

I got it fully working! I can login, share, join, it all works so far. Thank you @b333z and @phryneas for the foundation. My approach has been to just build it properly with Nix, but then work around the Nix store being readonly by copying over (and partially symlinking) the build to the VS code extensions directory. I removed all issues that caused it to error on startup. In its current form it is probably over patched, but at least it works.

https://gist.github.com/ottidmes/9360fc1f0fbd8443506b45c2149388a9

[ottidmes]

I fixed over patching the binaries and it still all works. I also improved the workaround to more precisely link those files that needed linking. And the workaround now only runs when the build has actually changed.

https://gist.github.com/ottidmes/9360fc1f0fbd8443506b45c2149388a9

[ottidmes]

The biggest problem the extension still had was that it did extensive diagnostic logging, filling up the journal. After many attempts* to silence it, I finally managed a solution that is simple yet effective, by preloading a library with a noop syslog function, it will stop logging.

*) redirecting stdout/stderr, checking for command line arguments, modifying the JS source code, LD_PRELOAD a customized connect, using unshare --mount to modify the log path, using GDB to close/modify file descriptors to the log, writing a UNIX socket filter (that one actually worked, but you lose the PID of what is let through to the journal)

https://gist.github.com/ottidmes/9360fc1f0fbd8443506b45c2149388a9

[phryneas]

I made a home-manager module to use your gist, seems to be working fine so far :)

https://gist.github.com/phryneas/9f2a4f7f10907f02bc36d44c9254ce50

Thanks for all your work!

[pinage404]

@phryneas i would love to have this module in the main repo of home-manager

(because other users can like it too and because i don't know to use this gist)

[phryneas]

It's still a bit messy and will need constant updating, so I'm not sure if it makes sense to add to home-manager.
But you can try to clean it up.

In the meantime, add this to your home.nix:

    imports = [
        "${builtins.fetchTarball {
            url = "https://gist.github.com/phryneas/9f2a4f7f10907f02bc36d44c9254ce50/archive/28bd9dcd18ae7280ee3ea40bd3db8a934f5b68a9.tar.gz";
            sha256 = "0gpi682rj8r6a5dqsqa9gnxawkzj5xfwm3find5x17mlb53w79cf";
        }}/home-manager-module.nix"
    ];

    services.vsliveshare = {
        enable = true;
        enableWritableWorkaround = true;
        enableDiagnosticsWorkaround = true; 
    };

[pinage404]

• I added it
• run home-manager switch (it works)
• start code with Live Share extension enabled

but the behavior is exactly the same as before

how should i debug this ? @phryneas

[phryneas]

First thought: did you uninstall the extension before all that? If not, you might now have it twice in ~/.vscode/extensions and code might start the wrong one.

Aside from that: debugging that is a combination of random logs, a crystal ball and some weird voodoo rituals. I don't really remember what I did - sorry :/

[aanderse]

@pinage404 did you end up getting this working?

[pinage404]

@aanderse nope =(

i did a VM with a Debian and VSCode that i start when i need to use Live Share

[ottidmes]

@aanderse @pinage404 Last week I had to use Live Share myself again, so I updated to the latest version, which required me to make a few slight changes (such as the patch), but other than that it still works fine: https://gist.github.com/ottidmes/9360fc1f0fbd8443506b45c2149388a9

Just remember to run systemctl --user start vsliveshare-writable-workaround.service, otherwise it will not write the patched version of the Live Share to the extensions directory.

[aanderse]

@danbst you've worked some vscode magic in the past... do you have any thoughts?

[ottidmes]

@aanderse Any thoughts towards what? If you read this thread you know that I successfully put it together so that it works under NixOS. So if you have any concrete questions as to what is not working for you, why not just ask me?

[aanderse]

@ottidmes seems like @pinage404 is still having some issues... so I was wondering if @danbst had any thoughts on how he might better debug/resolve them, given your solution.

I don't use vscode at all. Just looking to get issues resolved and closed.

[ottidmes]

@aanderse @Pneumaticat I think this issue can be closed, as the original issue has been resolved. When I find the time, I will try and make it easier to install, but since Live Share is still in active development and we need workarounds that are not fitting for inclusion in either Nixpkgs or home-manager, I will probably try and get it included in https://github.com/nix-community/NUR instead.

[aanderse]

Awesome!

[danbst]

sorry, I don't yet have a usecase for Live Share. home-manager or NUR module would be fine.

[BenBals]

@phryneas I get the following error when I paste your snippet from above:

error: The option value `systemd.user.services.vsliveshare-writable-workaround.Service.ExecStart' in `/nix/store/3hxy8h83s28i56fl5y39xzldykcgwbsj-source/home-manager-module.nix' is not of type `boolean or signed integer or string or list of boolean or signed integer or strings'.
(use '--show-trace' to show detailed location information)

[msteen]

@BenBals I have hosted the Live Share NixOS module in its own repository now. The home manager module of @phryneas is basically my module but tweaked to work with home manager. I however do not use home manager, so I have hosted my original work (which is just a regular NixOS module) updated to work for the extension version I am using. I am unable to test it (the package/module put in their own repo) until this evening, so I might have made a mistake somewhere, but it should work in theory, because the files are copied from my personal NixOS configuration project and I have used Live Share successfully some weeks ago with it.

{ ... }:

{
  imports = [
    (builtins.fetchTarball {
      sha256 = "1qmq5zwd4qdxdxh4zxc7yr7qwajgnsjdw2npw0rfkyahmrqw3j02";
      url = "https://github.com/msteen/nixos-vsliveshare/archive/86624fe317c24df90e9451dd5741220c98d2249d.tar.gz";
    })
  ];

  services.vsliveshare = {
    enable = true;
    enableWritableWorkaround = true;
    enableDiagnosticsWorkaround = true;
    extensionsDir = "/home/matthijs/.vscode/extensions";
  };
}

[aanderse]

Closing as per #41189 (comment)

[msteen]

I did an overhaul of the service, it works again with the latest version and should now be more robust.

@aanderse I also implemented an auto updater for it when it notices a new version is being installed in a similar manner as I did for ~/.vscode-server.

{
  imports = [
    "${builtins.fetchGit {
      url = "https://github.com/msteen/nixos-vsliveshare.git";
      ref = "refs/heads/master";
    }}"
  ];

  services.vsliveshare.enable = true;
}

[msteen]

@phryneas I updated the project to also support home manager and added the extensionsDir option again after looking at your fork (I thought that option did not really had a reason to exist, but was not aware of ~/.vscode-oss being used by the OSS fork). I don't use home manager myself, so could you report whether it works for you?

[phryneas]

@msteen I'll take a look on friday! Thank you so much for keeping this up.

[wmertens]

Wow I didn't find this when I encountered the same problem :(

@msteen I wrote a similar script but I think mine is faster (at least than the original above), since it only goes through the files once.

Too bad this got closed without any mention on the vscode pkg :(

[msteen]

@wmertens Not sure which exact scripts you are referring to, so I cannot really comment on that, but if you have some concrete improvements for vsliveshare on NixOS, a PR or issue at https://github.com/msteen/nixos-vsliveshare is most welcome.

Too bad this got closed without any mention on the vscode pkg :(

You mean the vsliveshare package in nixpkgs? What do you have in mind? Some comments in the code might still be missed. Maybe a warning should be added that can be disabled by passing some flag?

[wmertens]

How about:

• add a warning to the code wrapper that extensions installed by vscode might contain binaries and would need patching. Add a setting to disable the warning.
• make an optional code wrapper that patches binaries on startup and provides LD_LIBRARY_PATH from configurable libraries
  • I have the below, but the libraries need to be configurable and it doesn't skip patching if code is already running
  • Could additionally change the time stamps on everything to 0 so it's fast to find new files on startup

#! /usr/bin/env nix-shell
#! nix-shell -i sh -p dotnetCorePackages.netcore_3_1 icu patchelf gcc gcr liburcu openssl krb5 zlib gnome3.gnome-keyring libsecret desktop-file-utils xorg.xprop

# patch ELF loaders where needed
GCCLIB=$(dirname $(gcc -print-file-name=libstdc++.so.6))
LOADER=$(gcc -print-file-name=ld-linux-x86-64.so.2)
find ~/.vscode/extensions/ ~/.config/Code -type f -perm -100 -execdir patchelf --print-interpreter {} \; -print 2>/dev/null | awk '{t=$0;getline;if(t!~/^\/nix\//)print}' | while read f; do
	echo "Patching $f" >&2
	patchelf --set-interpreter "$LOADER" "$f"
	RPATH=$(patchelf --print-rpath "$f")
	patchelf --set-rpath "${RPATH+RPATH:}$GCCLIB" "$f"
done
# Provide all libraries
export LD_LIBRARY_PATH=$(echo "$NIX_LDFLAGS" | sed -E -e 's/\s*(-rpath|-L)\s*/:/g' -e 's/^://')
# It seems VSLS downloads dotnet itself so this may not be needed
export DOTNET_ROOT=$(dirname $(type -p dotnet))/..
# Don't know how to tell dotnet about ICU
export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
exec code "$@"

[pinage404]

There is an open issue in the repository of VSLS microsoft/live-share#3013

[VanCoding]

Just wondering, could this be fixed when using the vscode-with-extensions package as described here? Would be cool if the liveshare package was available directly by nixpkgs. It's a really cool extension and helps a lot when in homeoffice.

[jraygauthier]

Looks like https://github.com/msteen/nixos-vsliveshare/blob/master/pkgs/vsliveshare/default.nix is pretty much package-able as is.
@msteen: Any reason why not too?

[msteen]

@jraygauthier Its been a while, but if I remember correctly vsliveshare did not work correctly when used from /nix/store, since it needs its installation directly to be writable (among other things), which is not the case when you install the extension through vscode-with-extensions (then the extension directory becomes within /nix/store). That is why although I still build it with Nix, it is copied over to the extension dir (outside of /nix/store). And for it to properly run it also needs some patching, which AFAIK could not be done during build time. So, yes, that particular package could be included in Nixpkgs, but it would only give the false impression that it then could be installed through vscode-with-extensions. It does not work in isolation (without the fixes).

Although normally the extension directory is normally located in $HOME, it could in theory be anywhere, but this is true for most software configured in $HOME, and such software generally tends not be included in Nixpkgs. As NixOS is focused on system configuration, not user configuration. That among it changing a lot at the time, was the reason for me not to include it in Nixpkgs.

So in conclusion, although it could probably be upstreamed to Nixpkgs without too much problems, it is AFAIK not in line with what should be included in Nixpkgs.

[jraygauthier]

Thanks for the quick reply @msteen. Indeed attempted to use it (latest available version) with vscode-with-extensions. The extension indeed attempts to write various files (modifiedInternalSettings.json which I found a VSLS_SETTINGS_FILE="$PWD/test.json" dirty workaround) but I am now stuck with some ./dotnet_modules/vsls-agent.lock issue which for some obscure reason cannot be fixed with the usual touch ./dotnet_modules/vsls-agent.lock.

This whole vscode packaging thing that mutates its own install directory is becoming quite annoying as time passes. Those extensions developers really should avoid doing such things (in my opinion).

Any one knows how to get more debug information, the default log really is insufficient. I would like to get the debug log from out/prod/extension-prod.js (e.g.: debug('lockSync stale')).

Might give it another try later, but I assume that the extension code (*js) itself might require patching.

[cideM]

It shouldn't write to a directory relative to the plugin install dir though. Maybe it's possible to change upstream to respect the XDG specs?

[aaronjanse]

Maybe it's possible to change upstream

Or if not, at least patch on NixOS? Having VSCode Live Share work on NixOS would be very very useful :-)

[jraygauthier]

I do have something function based on @msteen's work now. @msteen: Are you ok with me creating a pull request (derivative work) from your work?

[msteen]

Having VSCode Live Share work on NixOS would be very very useful :-)

It does though? https://github.com/msteen/nixos-vsliveshare
Unless you meant with vscode-with-extensions, then sure.

@jraygauthier I am definitely OK with that! It would be awesome if you managed to get it to work when you just include it in vscode-with-extensions, without any additional fixes needed. If you do, be sure to make yourself the sole maintainer, as I don't actually use Live Share myself. And I think this project really needs an active maintainer, as many people truly depend on it for their work (some sadly even dropped NixOS because of it). I just like the idea of the feature and VS Code, but haven't really had the need myself.

[jraygauthier]

@msteen: Excellent. Nice to hear :) Added the PR.

[deviant]

Is this still an issue? As far as I can tell, all appropriate binaries are patchelf'd as of #100583 being merged.

[wmertens]

It works so-so. When I join a session, it takes several minutes unless I open a window with my old wrapper script and join from there.
It is very odd, the script opens a window with a differently colored status bar, and the joined window is regularly colored.

[deviant]

@wmertens What about as of latest VS Code and #115277?

[jraygauthier]

This latest PR (extension 1.03912) works fine here on nixos, using latest vscode 1.53.2, both local instances built from latest nixpkgs as follow:

$ cd /path/to/latest/nixpkgs
$ nix-build -I nixpkgs=. -E 'with import <nixpkgs> {config={allowUnfree = true;};}; vscode-with-extensions.override {vscodeExtensions = with vscode-extensions; [ms-vsliveshare.vsliveshare];}'
$ ./result/bin/code .

[wmertens]

Right, it broke, and @jraygauthier's instructions work great, thanks!

[winterqt]

@jraygauthier Your instructions don't seem to work as of some recent Nixpkgs commit (presumably ea67710, but haven't tested an older commit yet) - as I can't get the extension working anymore.

I'm trying with 2 different configurations:

1. Using home-manager's vscode.extensions list, which successfully installs the extension, but it does not function. (can provide logs if required)
2. Then, I saw your comment, and specified pkgs.vscode-with-extensions.override { vscodeExtensions = with pkgs.vscode-extensions; [ ms-vsliveshare.vsliveshare ]; } as the package to use, but was greeted with this error:

error: attribute 'pname' missing

       at /nix/store/bmf3jwgp67ixy8imw41rl68kmnhc1r4p-source/modules/programs/vscode.nix:9:17:

            8|
            9|   vscodePname = cfg.package.pname;
             |                 ^
           10|

Does anyone know a fix? Been trying to get this single extensions to work for an hour at this point 😅

cc @deviant as they've been fixing the extension it seems (great work by the way!)

[deviant]

@winterqt hi! looks like 2 is unrelated to the extension and rather because vscode-with-extensions does not have a pname. (I'm assuming you're setting programs.vscode.package = ... here, please correct me if I'm wrong)

This is a technically a bug in home-manager but is also kind of inherent to how wrapping works— wrapper derivations often have a different name to the package they're wrapping (and wrapped packages sometimes have a pname of <package>-unwrapped, etc), so it's not really safe to rely on. It's a wild west out here!

I would propose the following fix:

1. change vscode-with-extensions in nixpkgs to inherit passthru. this will expose the executableName attribute used by the VSCode, VSCodium, etc packages to identify which variant they are.
2. replace cfg.package.pname in home-manager with cfg.package.executableName

---

I'm not so sure about 1, could you open a new issue for that? I'm certain that the original issue is no longer relevant (#100583 should have fixed it, and my recent changes take care of it subsequently breaking again). I've tried what @jraygauthier wrote on latest nixos-unstable (f5e8bdd) and it works fine for me.

I don't know enough about how home-manager's vscode.extensions option functions to offer further insight right now, but I'd probably recommend using that over vscode-with-extensions if we can get it to work.

---

@aanderse mind closing this again? vsls-agent is wrapped now, which should resolve the original issue.

[jonringer]

This is somewhat addressed in #99968, libstdc++ would be available in the fhs environment. But not a complete solution, as buildFHSUserEnv isn't a perfect solution.