-
Notifications
You must be signed in to change notification settings - Fork 296
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot run under NixOS #1482
Comments
This is also reported by someone else in the workers-cli repo |
what does |
|
Hmm it sure looks like the libraries are there. I am not sure what would cause |
In that answer under solution one (manual), part of what's happening is that a not-found library is being resolved, while in our case here all of the binaries are present and have known paths. |
Following along further with that SE answer, I'm trying to run it with steam-run but encountering another issue first lol |
The problem can be located with the
#!/bin/sh
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt # https://github.com/cloudflare/workers-sdk/issues/3264
exec steam-run /path/to/workerd.orig "$@" Cloudflare should compile workerd as a static binary, as it has no interesting dependencies anyway. |
@ckiee your comment led me to figure out what happened. Thank you!
Checking the statically linked interpreter of $ file $(which hello)
# (output truncated)
# /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/ld-linux-x86-64.so.2 vs $ ldd ./workerd
# (output truncated)
# /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib64/ld-linux-x86-64.so.2 The difference between those two interpreter paths is # swaps `/lib64` to the resolved `/lib`
patchelf --set-interpreter /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/ld-linux-x86-64.so.2 ./node_modules/@cloudflare/workerd-linux-64/bin/workerd The binary becomes executable 🎉 I'm able to run |
Unfortunately, linking statically against glibc does not work, because glibc uses Therefore, we statically link everything except glibc. But it seems that NixOS isn't happy with such binaries, unless you use an extra wrapper. If there's something we could do that would make things easier on Nix without harming usability on other distros, we're happy to accept PRs. Unfortunately our team doesn't have the bandwidth to work on Nix support directly. |
@PsychoLlama Would you mind clarifying the solution a bit? Is patchelf a command that you run once to fix the linking, then workerd starts working properly? Where do I get the interpreter path for my machine, does that come from the |
TL;DR: I only need to patch it once. I got the expected path from Longer answerSure, I'll tell you what I can, but I think I'm still missing parts of the picture. If my first post was correct then patching the interpreter to use I also tried overriding the I no longer believe symlinking is the problem. I don't know why it fails. I'm still a noob when it comes to native stuff like this, so I might be missing something obvious. EDIT: While writing this response it occurs to me that
Yes, I only need to run it once after the first npm install, or any time the executable changes (e.g. updating the wrangler package).
I pulled it from
I just took the path that it printed and used that in the {
description = "Development environment";
outputs = { self, nixpkgs }:
let inherit (nixpkgs) lib;
in {
devShell = lib.genAttrs lib.systems.flakeExposed (system:
let pkgs = import nixpkgs { inherit system; };
in pkgs.mkShell {
nativeBuildInputs = [ pkgs.nodejs ];
# See: https://github.com/cloudflare/workerd/issues/1482
shellHook = ''
__patchTarget="./node_modules/@cloudflare/workerd-linux-64/bin/workerd"
if [[ -f "$__patchTarget" ]]; then
${pkgs.patchelf}/bin/patchelf --set-interpreter ${pkgs.glibc}/lib/ld-linux-x86-64.so.2 "$__patchTarget"
fi
'';
});
};
} Now every time I enter my dev shell it will auto-correct the workerd interpreter path. You may need to change |
@jonahbron Ha, while poking around, I discovered a simpler alternative: remove wrangler from your I think through troubleshooting this issue, I rediscovered why the fixup phase of |
Oh my god you're a life saver @PsychoLlama, installing with
Moving the flake down into the child directory fixed that issue. Only drawback is I have to invoke wrangler directly (can't have it in a package.json) script because it will search in |
I'm going to move this issue to a discussion as it does not appear as if this is actually an issue to resolve in workerd itself. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Running workerd-linux-64 under linux should be possible with just installing glibc according to the readme. However when I try to execute it, I get this error:
This is running in a Nix shell with nixpkgs.glibc present (and verified by running the binaries it provides)
The text was updated successfully, but these errors were encountered: