-
Notifications
You must be signed in to change notification settings - Fork 64
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
Error: Spawning of process failed
caused by choosenim using a wrapper process (shim) instead of symbolic link
#126
Comments
Error: Spawning of process failed
caused by choosenim using a wrapper processError: Spawning of process failed
caused by choosenim using a wrapper process instead of symbolic link
IIRC the main reason I chose to do it this way is simplicity, supporting both symlinks and this proxy exe would have been more complex. To be honest I think the underlying bug should be fixed, even if choosenim uses symlinks it won't fix this problem. |
windows can use symlinks too, eg https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ |
hopefully fixed by nim-lang/Nim#13232 but still, symlinks should be used IMO |
actually, this is not fixed, shim/wrapper process causes the following issue:
Process 59025 exited with status = 1 (0x00000001) |
Error: Spawning of process failed
caused by choosenim using a wrapper process instead of symbolic linkError: Spawning of process failed
caused by choosenim using a wrapper process (shim) instead of symbolic link
Is this with latest version of choosenim? Can you reproduce it? Does it happen with older versions too? |
thanks for re-opening, see also nim-lang/Nim#16838 which lists several issues caused by shims instead of symlinks (including one that prevents using testament in This is an important issue that should be tracked and eventually fixed.
yes.
yes, i retried with latest choosenim (0.7.4) and it results in same error as #126 (comment) for any shim generated by choosenim / proxyexe.
how do I build a shim?
fails with: |
Can you just grab the choosenim release from the releases page and use it to install Nim somewhere? You can set a new $HOME or whatever to not overwrite your existing install. |
0.3.0HOME=/tmp/d09c /Users/timothee/Downloads/choosenim-0.3.0_macosx_amd64 1.4.2 lldb -o r -o quit /tmp/d09c/.nimble/bin/nim
0.7.5HOME=/tmp/d09b /Users/timothee/Downloads/choosenim-0.7.5-20210102-f338473_macosx_amd64 1.4.2 build from source on latest choosenim mastergit rev-parse HEAD
|
minimized repro: import osproc
proc main()=
let exePath = "/Users/timothee/git_clone/nim/Nim_devel/bin/nim"
let p = startProcess(exePath, options={poParentStreams})
let exitCode = p.waitForExit()
p.close()
main() nim c -o:/tmp/z01 main /Users/timothee/git_clone/nim/timn/tests/nim/all/t11753.nim(14) t11753 so this points to a nim bug that I'll file and is (hopefully) fixable via something similar to nim-lang/Nim#13232; however, the remaining issues I raised in nim-lang/Nim#16838 are still valid, so there should be at least 1 bug open to track it |
choosenim is implemented by a binary that dispatches to the real nim binary; this prevents using
lldb -- nim c -r foo
, at least on OSX:I'm curious why isn't choosenim using symbolic links (at least on posix) which seems a simpler approach and avoids this kind of problem ? maybe I'm missing something?
i'm on OSX (where gdb isn't supported, only lldb)
but this bug has always been there
EDIT: related to nim-lang/Nim#9634; I may have a patch but no PR yet; but still genuinely curious why can't symbolic links be used instead, on posix?
The text was updated successfully, but these errors were encountered: