Skip to content

Vagrant on Windows and Tutorial 5 incompatible #77

@chrysn

Description

@chrysn

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).

[edit: Link to the discussion in which this came up]

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions