install lsp on debian (glibc issue)

[elasticspoon]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

I am trying to install postgrestools on debian bookworm and I have tried both the npm installation method and the binary installation method and neither work. Any suggestions?

Via binary:

$ > curl -L https://github.com/supabase-community/postgres-language-server/releases/download/0.2.1/postgrestools_x86_64-unknown-linux-gnu -o ~/.local/bin/postgrestools
chmod +x ~/.local/bin/postgrestools
postgrestools check test.sql
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 24.3M  100 24.3M    0     0  41.7M      0 --:--:-- --:--:-- --:--:-- 41.7M
postgrestools: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by postgrestools)

Via NPM:

$ > npm install --save-dev --save-exact @postgrestools/postgrestools
npx postgrestools check test.sql


added 1 package, and audited 2 packages in 2s

found 0 vulnerabilities
node:internal/modules/cjs/loader:1412
  throw err;
  ^

Error: Cannot find module '@postgrestools/cli-x86_64-linux-gnu/postgrestools'
Require stack:
- /home/bandito/Projects/rideshare/node_modules/@postgrestools/postgrestools/bin/postgrestools
    at Function._resolveFilename (node:internal/modules/cjs/loader:1409:15)
    at Function.resolve (node:internal/modules/helpers:145:19)
    at Object.<anonymous> (/home/bandito/Projects/rideshare/node_modules/@postgrestools/postgrestools/bin/postgrestools:27:13)
    at Module._compile (node:internal/modules/cjs/loader:1739:14)
    at Object..js (node:internal/modules/cjs/loader:1904:10)
    at Module.load (node:internal/modules/cjs/loader:1473:32)
    at Function._load (node:internal/modules/cjs/loader:1285:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:234:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:151:5) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/bandito/Projects/rideshare/node_modules/@postgrestools/postgrestools/bin/postgrestools'
  ]
}

Node.js v23.6.1

System information

• OS: debian bookworm

[psteinroe]

we currently don't seem to provide a prebuilt for GNU.

Can you try building it from source? we will check why the build does not work properly.

cc @juleswritescode

[psteinroe]

@elasticspoon what glibc version do you have installed?

[juleswritescode]

@elasticspoon When I run docker run -it debian:bookworm and check ldd --version, I'm getting version 2.36.
The current Rust targets require version 2.39, so that seems to be the issue… I'm not sure why bookworm uses such an old version for glibc.

Is upgrading the glibc an option?

[rafmagns-skepa-dreag]

Unfortunately, upgrading glibc is only very rarely an option - saying this is almost always is asking the user to either upgrade to a different version of their OS or risk breaking their OS. In the circumstance above, glibc 2.36 (2022-08-01) is only one version behind the max released version when debian bookworm was released (2023-06-10) and, if I understand correctly, it's very rare that distros upgrade glibc on the same major OS version. Personally, I'm stuck with 2.34 (2021-08-02) for the next 5+? years because we use Rocky 9 (initial release 2022-07-14, full EOL 2032-05-31). I appreciate that 2.39 (2024-01-31) is more than a year old but, imo, many people use LTS releases and it would be extraordinarily helpful to offer binaries for older glibc

[AndrewJackson2020]

Unfortunately, upgrading glibc is only very rarely an option - saying this is almost always is asking the user to either upgrade to a different version of their OS or risk breaking their OS. In the circumstance above, glibc 2.36 (2022-08-01) is only one version behind the max released version when debian bookworm was released (2023-06-10) and, if I understand correctly, it's very rare that distros upgrade glibc on the same major OS version. Personally, I'm stuck with 2.34 (2021-08-02) for the next 5+? years because we use Rocky 9 (initial release 2022-07-14, full EOL 2032-05-31). I appreciate that 2.39 (2024-01-31) is more than a year old but, imo, many people use LTS releases and it would be extraordinarily helpful to offer binaries for older glibc

I am in the same position. I was not able to use the complied release binaries and had to build them myself to get them working. I'm sure many people are in the same position. Some perspective users might not have the time/knowledge to compile binaries that work on their system and just move on to other things instead. Highly recommend targeting a glibc version that works for systems that are older but not yet EOL.

[juleswritescode]

Thank you for the feedback. I'll check out whether we can adjust the compile targets such that we use an older version 👍

[elasticspoon]

@elasticspoon When I run docker run -it debian:bookworm and check ldd --version, I'm getting version 2.36. The current Rust targets require version 2.39, so that seems to be the issue… I'm not sure why bookworm uses such an old version for glibc.

Is upgrading the glibc an option?

Just to confirm what others are saying, yea its an older glibc that probably won't get upgraded until debian upgrades (not sure how that bit works).

130 > ldd --version
ldd (Debian GLIBC 2.36-9+deb12u9) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

I would love if you could update the compile targets because I how no clue how I would build a binary to use the older glibc. FWIW these are the glibc versions being used on debian: https://tracker.debian.org/pkg/glibc

[elasticspoon]

we currently don't seem to provide a prebuilt for GNU.

Can you try building it from source? we will check why the build does not work properly.

cc @juleswritescode

Could you give me a run down of how I would do that? Or a link? Totally unfamiliar with rust and don't see anything like a Makefile.

[rafmagns-skepa-dreag]

@juleswritescode thanks! appreciate you looking into this change

[AndrewJackson2020]

we currently don't seem to provide a prebuilt for GNU.
Can you try building it from source? we will check why the build does not work properly.
cc @juleswritescode

Could you give me a run down of how I would do that? Or a link? Totally unfamiliar with rust and don't see anything like a Makefile.

The README used to have build instructions but they were removed with commit 46b679a. Would be very helpful if build instructions were added to the README or at least a link to a separate document that has build instructions.

[psteinroe]

just fyi: we have an issue with a dependency that prevents gnu builds in general at the moment.

fixing this upstream now, and will do a new release + add the build from source instructions afterwards.

[psteinroe]

for what its worth: upstream issues are resolved :)

[elasticspoon]

I have not had time to try to build this from source but #318 reads like next release might fix this?

[juleswritescode]

@elasticspoon I think so! The Ubuntu-22.04 runner uses glibc version 2.35, so the binary should work with 2.36.

I also tried the Ubuntu-20.04 runner, which uses glibc 2.31, but then we would get more issues with upstream dependencies.

Hopefully, 2.35 will already help many people.

We'll also add instructions to build from source again. 👍

[Terbium-135]

Waiting for that fix.
Thanks for all your work!

[juleswritescode]

Version 0.4.0 includes the fix and is released. Can you try again? :)

[elasticspoon]

$ > postgrestools check test.sql
Checked 1 file in 5ms. No fixes applied.

Eyyyy. It works! Thanks a bunch @juleswritescode! Feel free to close the issue.