Groups 104 of 99+ julia-users › Windows subsystem for Linux 12 posts by 5 authors Bill Hart Aug 3 I got the Windows 10 anniversary update and turned on the new Windows subsystem for Linux. The Julia binaries from the website load, but unfortunately don't fully work. I had hoped Julia might just work as I had heard many large programs just work, but alas, not yet. I tried both 0.4.6 and 0.5.0-pre Julia binaries from the website. It seems the subsystem returns a Not Enough Memory error whenever Julia tries to spawn, which it does pretty often. This seems to be the main and perhaps only problem preventing Julia 0.4.6 working for now. I tried defining a function and running it, and this caused no issues. There are also double free or corruption errors with Julia 0.5.0. Note that I am only getting this in Julia 0.5.0, not anything else, e.g. Sage seems to work ok and passes much of its test suite without any such errors. Apart from the spawn issue, Julia 0.4.6 also doesn't have this problem. I tried building Julia 0.4.6 from source and the main issue I hit was that pcre2 requires a stack limit of 16MB, but WSL is limited to 8MB. There is a build option for pcre to use heap instead of stack, but it obviously hasn't been maintained. It still complains it can't set the stack to the right limit. And ulimit refuses to increase the limit. I ended up just replacing the relevant test code with an empty shell script so the build could continue. Also, when building LLVM and fftw it frequently corrupted the .o files, so some of them had to be built more than once to get a valid .o file. This seems to be avoidable by not doing a parallel build. But of course that takes a very long time. BLAS seems to take an extremely long time to build, making building from source pretty much impractical on the subsystem at present. It takes many hours. The main problem seems to be the glacially slow filesystem. The compute performance seems to be isomorphic to a real Ubuntu server in the tests I've done, including ones that allocate lots of memory. Of course slow build times are not that important given that it is supposed to work with standard Ubuntu binaries which can be built elsewhere. I was able to get the build to complete though and Julia 0.4.6 ran, but it has the same issue with spawn as with the binaries on the Julia website, e.g. julia run `ls` ERROR: could not spawn `ls`: not enough memory ENOMEM in -jl_spawn at process-jl:262 in anonymous at process-jl:415 in setup_stdio at . process-jl:403 in __spawn 58__ at . process-jl:414 in run at . process-jl:530 There should be enough memory on this machine. I think the message is caused by some other issue. Bill. Bill Hart Aug 3 Julia seems to use an old version of libuv. People have noticed that libuv has problems on WSL. I don't know whether these have been fixed or not. I couldn't find any specific tickets for it. But perhaps the latest libuv works on WSL and maybe that points to a possible solution. Bill. Bill Hart Aug 3 In fact, both the old and new versions of libuv seem to fail their test suites on WSL. I imagine they tie into the system calls pretty tightly and Microsoft may not have implemented them all fully or correctly as of the moment. Perhaps things will improve with the next release of WSL. Bill. On Wednesday, 3 August 2016 18:23:53 UTC+2, Bill Hart wrote: Julia seems to use an old version of libuv. People have noticed that libuv has problems on WSL. I don't know whether these have been fixed or not. I couldn't find any specific tickets for it. But perhaps the latest libuv works on WSL and maybe that points to a possible solution. Bill. Stefan Karpinski Aug 3 Would be great to get this working. Maybe open an issue to track this? Isaiah Aug 3 Re: julia-users Re: Windows subsystem for Linux Tony has been trying this too and has reported upstream. See https: github.com Microsoft BashOnWindows issues 118 issuecomment-208249048 Bill Hart Aug 3 I agree, it would be great to get it going. I'll open a ticket later on tonight or tomorrow. I'm not sure I can contribute much more to it myself. I think the first thing to do might be to contact the libuv people and ask them whether libuv is expected to run on WSL. It may just be a waiting game, until Microsoft are able to implement enough syscalls for them. Bill. Tony Kelman Aug 4 I don't think there's anything specific we can fix here, we have to wait for Microsoft to gradually fix the rest of the syscalls they haven't implemented all the way yet. Good to know this is available without having to opt in to the unstable test builds of Windows 10 now. Last I looked at it, the build performance was far better than compiling Julia from source in Cygwin or MSYS2, but not quite as good as Linux. I imagine it would be much slower if you build in a mnt c location and according to David Anthoff, autotools in patchelf has some issues there, probably related to file timestamps , better to stay within the WSL home filesystem. As long as you do that you can compile Julia from source as if you're on normal Ubuntu, but it won't pass all of the tests. Parallelism won't work until they fix getifaddrs for example. Bill Hart Aug 4 Ok, I'll hold off making a ticket then. Tony, do you think the double free and corruption with Julia 0.5.0 could be independent of Microsoft. I'm not seeing that behaviour anywhere else. Do we have any tools that might help track it down? Or is it just not worth it for now? Bill. Tony Kelman Aug 4 Maybe. What are you running that hits a double free? Does it happen when run in julia-debug? What about under gdb? Bill Hart Aug 4 It just happens during precompilation I think. I'll look into it and see if I can get some more information. Páll Haraldsson Aug 11 On Wednesday, August 3, 2016 at 3:07:55 PM UTC, Bill Hart wrote: I got the Windows 10 anniversary update and turned on the new Windows subsystem for Linux. You mean the subsystem and bash is no non-beta Insder program, good to know, and useful for software that isn't already portable to Windows. The Julia binaries from the website load, but unfortunately don't fully work. Why would it be great to get this working ? Or at least of interest for you? I also did wander if it would work but since there is a Windows Julia binary, that we would want to maintain for a long time and not drop support of Julia that way, I do not see this as a priority, or on the horizon. Only that Julia version is supported back to Windows XP. Theoretically using a Linux ELF binary in Windows is interesting, but it could be a long time to a Windows 10-exclusive world ? . There are also double free or corruption errors with Julia 0.5.0. I don't understand, only in the Windows subsystem, but not same double free under Linux with same ELF binary? How can that happen, it's Julia that does the free and malloc ?! I tried building Julia 0.4.6 from source and the main issue I hit was that pcre2 requires a stack limit of 16MB, but WSL is limited to 8MB. And ulimit refuses to increase the limit. I've never understood why there are limits, such as on file descriptors except if you want to artificially limit , except for the fundamental memory limit and in a sense CPU time . I guess the stack is a special case but could also in theory be unlimitted? . Different cross-platform limits just makes them worse.. E.g. file descriptors are just memory to the kernel in the end? The main problem seems to be the glacially slow filesystem. Also interesting, just on the subsystem that is, otherwise ok? -- Palli. Bill Hart Aug 11 Re: julia-users Re: Windows subsystem for Linux Translate message to English On 11 August 2016 at 10:47, Páll Haraldsson pall.ha... gmail.com wrote: On Wednesday, August 3, 2016 at 3:07:55 PM UTC, Bill Hart wrote: I got the Windows 10 anniversary update and turned on the new Windows subsystem for Linux. You mean the subsystem and bash is no non-beta Insder program, good to know, and useful for software that isn't already portable to Windows. The Julia binaries from the website load, but unfortunately don't fully work. Why would it be great to get this working ? Or at least of interest for you? I also did wander if it would work but since there is a Windows Julia binary, that we would want to maintain for a long time and not drop support of Julia that way, I do not see this as a priority, or on the horizon. Only that Julia version is supported back to Windows XP. Theoretically using a Linux ELF binary in Windows is interesting, but it could be a long time to a Windows 10-exclusive world ? . The reason this could be interesting for some people is that not all Clanguage libraries have been ported to Windows, and doing so is non-trivial. For example, we'd like to rely on Singular and Gap and don't currently have the resources to do a port. However, they work just fine on Ubuntu. Of course supporting the WSL does not mean abandoning support for native Windows. Bill.