tup doesn't work on WSL

[thoni56]

As mentioned in this comment to another issue tup does not currently (Linux 4.4.0-18362-Microsoft #836-Microsoft) work on WSL.

Pity, since I just added Tupfiles to my project ;-(

[gittup]

Are you using WSL1 or WSL2? And what failure are you seeing?

[thoni56]

I suppose I'm on WSL 1 still (1909). I get

fuse: device not found, try 'modprobe fuse' first

and when I try that

modprobe: FATAL. Module fuse not found in directory /lib/modules/4.4.9-18362-Microsoft

I'll try to move to WSL 2 and see if that helps.

[gittup]

If FUSE isn't supported in WSL, you could try to build tup with the ldpreload server instead. You can use bootstrap-ldpreload.sh to bootstrap tup without FUSE, just make sure to have CONFIG_TUP_SERVER=ldpreload in tup's tup.config as well. Eg:

$ cd tup
$ echo 'CONFIG_TUP_SERVER=ldpreload' > tup.config
$ ./bootstrap-ldpreload.sh
$ ./tup server
ldpreload

If the last step says "fuse", then tup is built with the fuse server (the default). Please report any other issues you find. I haven't used WSL before, but I'll try to set it up soon.

[thoni56]

Actually, since there seems to be some benefits of using WSL 2 (real Linux kernel and some speed) I upgraded to WSL 2. And initial tests indicate that tup works as is should on WSL 2. But I hope somebody else benfits from the additional info for WSL 1.

[gittup]

I installed WSL1 and confirmed that building with CONFIG_TUP_SERVER=ldpreload in tup.config at least compiles successfully. Many test cases pass, but unfortunately file locking is broken in WSL1 (microsoft/WSL#1927) which prevents both the ldpreload server and sqlite from working correctly with multiple processes.

As such, the file monitor (tup monitor) isn't usable since it relies on file locking to prevent multiple processes from accessing the database, and tup will intermittently fail to process dependencies if the subprocess runs multiple processes in parallel. For example, t4027 runs a shell script which spawns a grep and an echo to run in parallel, and frequently results in a corrupt dependency file. Compiling multiple C files with gcc in parallel is fine, since each command writes to a separate dependency file, and gcc's internal subprocesses all run sequentially.

I would suggest nobody try using tup in WSL1 until they fix locking. Are you able to get test cases to pass in WSL2?

[thoni56]

I did not/haven't built tup from source but are running tup 0.7.8-3 [debian]. I've been running it of and on for the last couple of weeks and have seen no problems in WSL 2 (4.19.104-microsoft-standard).