Vscode-remote-release: Remote-SSH fails on non-glibc Linux instances.

[alyx]

• VSCode Version: 1.35.0-insiders
• OS Version: Windows 10 / Linux

Step 1. Using Remote-SSH, attempt to connect to a Linux server using musl instead of glibc (e.g. Alpine, select Gentoo instances, etc.).

alyx on baptiste ~/.vscode-remote/bin/4ca38ce5584d7cd67b435b3c32ef1240c6a29628 $ ldd node
        /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f436f29b000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f436f084000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f436f63e000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by node)
Error relocating node: gnu_get_libc_version: symbol not found
Error relocating node: __register_atfork: symbol not found
Error relocating node: __strdup: symbol not found
Error relocating node: setcontext: symbol not found
Error relocating node: makecontext: symbol not found
Error relocating node: backtrace: symbol not found
Error relocating node: getcontext: symbol not found

(Would affect any prebuilt binary, not just node; however this was the first binary found in the .vscode-remote folder)

Does this issue occur when all extensions are disabled?: No -- this issue is specifically in regards to the Remote-SSH extension.

Best resolution while still using prebuilt binaries would be to check for /lib64/ld-linux-x86-64.so or /lib/ld-musl-x86_64.so.1 and download an alternate binary based on results. Would require compiling on more than one platform but would allow for support on a wider range of Linux products.

[roblourens]

Related to https://github.com/microsoft/vscode-remote-release/issues/103 also

[Chuxel]

And https://github.com/microsoft/vscode-remote-release/issues/54

[awilfox]

Can you test this on an Adélie Linux machine with the latest gcompat package installed?

[alyx]

@awilfox

alyx on junkrat ~/.vscode-remote/bin/4ca38ce5584d7cd67b435b3c32ef1240c6a29628 $ apk list gcompat
gcompat-0.4.0-r0 x86_64 {gcompat} (UoI-NCSA) [installed]

alyx on junkrat ~/.vscode-remote/bin/4ca38ce5584d7cd67b435b3c32ef1240c6a29628 $ ./node
-bash: ./node: No such file or directory
alyx on junkrat ~/.vscode-remote/bin/4ca38ce5584d7cd67b435b3c32ef1240c6a29628 $ file node
node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=42c88d3401728b722d7ea3e700cb81f90ec1cfb6, with debug_info, not stripped
alyx on junkrat ~/.vscode-remote/bin/4ca38ce5584d7cd67b435b3c32ef1240c6a29628 $ ldd node
        /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f1cc5976000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f1cc575f000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f1cc5d19000)
        ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f1cc555a000)
Error relocating node: gnu_get_libc_version: symbol not found
Error relocating node: __register_atfork: symbol not found
Error relocating node: __strdup: symbol not found
Error relocating node: setcontext: symbol not found
Error relocating node: makecontext: symbol not found
Error relocating node: backtrace: symbol not found
Error relocating node: getcontext: symbol not found

[awilfox]

"No such file or directory" -> try ln -s /lib /lib64. You may also need to do the same with /usr/lib.

[alyx]

Well that fixed the first problem!
New one:

[awilfox]

That looks like https://github.com/libuv/libuv/commit/afc05a3ab0ad2ab79385f3e3f029eb34849eda0e.

Is there any way to convince VSCode to use a system-provided Node.js? That would probably make things significantly easier, assuming it works with the LTS version.

[Nowaker]

Same problem on armv7l architecture - device is Turris Omnia.

root@nwkr-omnia ..e414d9e4239a252d1ab117bd7067f125afd80a # file node
node: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 4.4.174, with debug_info, not stripped
root@nwkr-omnia ..e414d9e4239a252d1ab117bd7067f125afd80a # ldd node
    /lib/ld-linux-armhf.so.3 (0xb6ec8000)
    libdl.so.2 => /lib/ld-linux-armhf.so.3 (0xb6ec8000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6db4000)
    libm.so.6 => /lib/ld-linux-armhf.so.3 (0xb6ec8000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d99000)
    libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0xb6ec8000)
    libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6ec8000)
Error relocating node: __register_atfork: symbol not found
Error relocating node: __strdup: symbol not found
Error relocating node: gnu_get_libc_version: symbol not found
Error relocating node: setcontext: symbol not found
Error relocating node: backtrace: symbol not found
Error relocating node: makecontext: symbol not found
Error relocating node: getcontext: symbol not found

Given musl is supported on Alpine, would it be possible to get arm64 on musl working any soon?

[Nowaker]

Hmm... This was enough to get it working:

ln -sf `which node` /root/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a/node

[sacvalleytech]

works with libstdc++(10.2.1_pre1-r1)

I had to get it from Alpine Edge... 3.12 does not seem to contain the right package versions to get this working

VsCode Insiders (commit: ac165d7f974d70212be80cb15eaecfc1fd20b21a)

[sacvalleytech]

That looks like libuv/libuv@afc05a3.

Is there any way to convince VSCode to use a system-provided Node.js? That would probably make things significantly easier, assuming it works with the LTS version.

Alpine libuv package has this patch: https://git.alpinelinux.org/aports/commit/?id=c94bbcd862946e8a4c7d1db89d9822b494f60c34

Interestingly VsCode Server Insiders worked with the below commit (no hacks)

VsCode Server Insiders (ac165d7f974d70212be80cb15eaecfc1fd20b21a) -- ~ 12-6-2020

• contains NodeJS v12.18.3
• need to use v10 libc packages on Alpine Edge to avoid symbol not found errors

However subsequent builds are failing

VsCode Server Insiders (bc13785d3dd99b4b0e9da9aed17bb79809a50804) -- ~ 12-10-2020

• contains NodeJS v12.14.1 (note the _lower_ NodeJS version number)
• errors with Assertion failed: process_title.len + 1 == size (../deps/uv/src/unix/proctitle.c: uv_setup_args: 69)

Comparing the NodeJS source code of deps/uv/src/unix/proctitle.c between v12.14.1 & 12.18.3... you can see a few changes have been made including removing much of the aforementioned patch.... not sure why MS downgraded the NodeJS version but this seems to be the issue

v12.14.1

int uv_set_process_title(const char* title) {
  uv_once(&process_title_mutex_once, init_process_title_mutex_once);
  uv_mutex_lock(&process_title_mutex);

  if (process_title.len != 0) {
    /* No need to terminate, byte after is always '\0'. */
    strncpy(process_title.str, title, process_title.len);
    uv__set_process_title(title);
  }

  uv_mutex_unlock(&process_title_mutex);

  return 0;
}

v12.18.3

int uv_set_process_title(const char* title) {
  struct uv__process_title* pt;
  size_t len;

  pt = &process_title;
  len = strlen(title);

  uv_once(&process_title_mutex_once, init_process_title_mutex_once);
  uv_mutex_lock(&process_title_mutex);

  if (len >= pt->cap) {
    len = 0;
    if (pt->cap > 0)
      len = pt->cap - 1;
  }

  memcpy(pt->str, title, len);
  memset(pt->str + len, '\0', pt->cap - len);
  pt->len = len;

  uv_mutex_unlock(&process_title_mutex);

  return 0;
}