You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Windows users run tutorial 5 in vagrant, they can get stuck at running the second instance:
user@riot-vm:/home/vagrant/Tutorials/task-05$ make all term PORT=tap1
Building application "Task05" for "native" with MCU "native".
[...]
/usr/bin/ld: cannot open output file /home/vagrant/Tutorials/task-05/bin/native/Task05.elf: Text file busy
collect2: error: ld returned 1 exit status
/home/vagrant/Tutorials/task-05/../RIOT/Makefile.include:594: recipe for target '/home/vagrant/Tutorials/task-05/bin/native/Task05.elf' failed
make: *** [/home/vagrant/Tutorials/task-05/bin/native/Task05.elf] Error 1
user@riot-vm:/home/vagrant/Tutorials/task-05$
This seems to be because at some point there is still a Windows file system and a Windows kernel executing the processes, and that OS is a bit picky when it comes to overwriting a currently running executable (AFAICT it doesn't think with inodes).
I don't have that system set up here so I can't experiment on this (just relaying from a support request on #riot-os), but whoever added the recommendation to use Vagrant on Windows can probably tell more about whether this is just because there's a forwarded file system or whether it's some WSL1 thing where the process is actually launched as a Windows process. If it's the latter, can this all move to WSL2 where there's a real Linux kernel?
If not, it may be an option to say something like
If you're running on Windows, you'll need a separate tutorials checkout for each instance, otherwise you get errors like cannot open output file [...]/Tutorials/task-05/bin/native/Task05.elf: Text file busy.
(In theory it would be an option to copy the binary over in the make term target, but I fundamentally oppose adding workarounds for OSs that try to sneak back into looking like a viable platform for development by emulating UNIX but doing it so badly that people start to make exceptions for them again anyway just because they either don't get it right or worse choose not to).
When Windows users run tutorial 5 in vagrant, they can get stuck at running the second instance:
This seems to be because at some point there is still a Windows file system and a Windows kernel executing the processes, and that OS is a bit picky when it comes to overwriting a currently running executable (AFAICT it doesn't think with inodes).
I don't have that system set up here so I can't experiment on this (just relaying from a support request on #riot-os), but whoever added the recommendation to use Vagrant on Windows can probably tell more about whether this is just because there's a forwarded file system or whether it's some WSL1 thing where the process is actually launched as a Windows process. If it's the latter, can this all move to WSL2 where there's a real Linux kernel?
If not, it may be an option to say something like
(In theory it would be an option to copy the binary over in the
make term
target, but I fundamentally oppose adding workarounds for OSs that try to sneak back into looking like a viable platform for development by emulating UNIX but doing it so badly that people start to make exceptions for them again anyway just because they either don't get it right or worse choose not to).[edit: Link to the discussion in which this came up]
The text was updated successfully, but these errors were encountered: