Building Carbon on Windows without WSL

[mmdriley]

Building on Windows is low priority but it may be helpful to have a common place where we keep track of known problems.

The first problem I hit was https://github.com/google/llvm-bazel fails if it can't create symlinks, which Windows doesn't allow by default for unprivileged users. This can be changed by enabling Developer Mode.

Current blocker is our toolchain configuration expects to find Clang at bin/clang but it's bin/clang.exe. Once that's fixed I assume there will be wrinkles around turning clang.exe into clang++.exe.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

[mmdriley]

Can you say a bit more about the program you wrote? Was this a batch file? An executable that used ShellExecute? Etc.

[jonmeow]

Note, #1754 is already working on this and I think it's using a better approach.

[mmdriley]

Agree that #1754 looks like a good path forward for resolving this issue.

The "Shell" in ShellExecute is the Windows shell (GUI), i.e. Explorer. Not command or cmd. That said, CreateProcess does some fun parsing too.

[Jeangowhy]

My case is “no such package '@llvm-project//llvm'”
Windows 10

ERROR: C:/download/carbon/explorer/BUILD:33:10: //explorer:explorer depends on @llvm-project//llvm:Support in repository @llvm-project which failed to fetch. no such package '@llvm-project//llvm': Failed to execute overlay script: 'C:/MinGW/bin/python3.exe C:/users/ocean/_bazel_ocean/r4bacw7r/external/llvm-raw/utils/bazel/overlay_directories.py --src C:/users/ocean/_bazel_ocean/r4bacw7r/external/llvm-raw --overlay C:/users/ocean/_bazel_ocean/r4bacw7r/external/llvm-raw/utils/bazel/llvm-project-overlay --target .'
Exited with code 256
stdout:

stderr:
Timed out

[ddkwork]

Unfortunately, China's network access is limited, and bazel stays in a loop loading dependencies, so I'm willing to try compiling carbon if it works out of the box like cmake.

[jonmeow]

@ddkwork This issue is about building Carbon for development (on Carbon, not using Carbon) on Windows. Cmake support for releases is separate (could probably done with add_custom_command already, but Carbon's not stable enough to make it a priority).

[jonmeow]

Note, WSL hasn't been mentioned here, but it's my understanding that it generally works. It might still be worth keeping this for native use of bazel to build Carbon on Windows.

[ddkwork]

Note, WSL hasn't been mentioned here, but it's my understanding that it generally works. It might still be worth keeping this for native use of bazel to build Carbon on Windows.

The only way I've tried to use bazel is with clion, and as I mentioned before, either compiling carbon explorer or using explorer to compile carbon code is a terrible operation as long as it requires that you have to use bazel, for China only, as China has no access to the various packages and deps of bazel, and unless there's an official public proxy or mirror, the nuisance caused by bazel is a pain in the ass.

[chandlerc]

Note, WSL hasn't been mentioned here, but it's my understanding that it generally works. It might still be worth keeping this for native use of bazel to build Carbon on Windows.

The only way I've tried to use bazel is with clion, and as I mentioned before, either compiling carbon explorer or using explorer to compile carbon code is a terrible operation as long as it requires that you have to use bazel, for China only, as China has no access to the various packages and deps of bazel, and unless there's an official public proxy or mirror, the nuisance caused by bazel is a pain in the ass.

Sorry its frustrating. =/

We get a lot of benefit from Bazel and being able to scale out our dependencies though. There does seem to be instructions for separating when Bazel accesses the internet: https://bazel.build/run/build#running-bazel-airgapped

I've not tried the repository cache approach, but if you or anyone else tries it out and has useful instructions for how to set it up and what to expect, I think that would be a great contribution to our docs to help folks out where internet access isn't easy.

Beyond that, we are now publishing nightly builds here:
https://github.com/carbon-language/carbon-lang/releases

These should work on WSL, and don't require Bazel or anything else -- you can just extract and try things out. It only has the toolchain, not the explorer, as that's where most of our focus is these days. In general, I would expect these nightly builds to get better and better and be a much easier way to try something out quickly than building everything from source. The latter is really for folks who want to contribute to Carbon.

[ddkwork]

i can not open this link https://bazel.build/run/build#running-bazel-airgapped And the released bin seems not supposed Windows?

…

---Original--- From: "Chandler ***@***.***> Date: Mon, Jul 1, 2024 13:44 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [carbon-language/carbon-lang] Building Carbon on Windows withoutWSL (#298) Note, WSL hasn't been mentioned here, but it's my understanding that it generally works. It might still be worth keeping this for native use of bazel to build Carbon on Windows. The only way I've tried to use bazel is with clion, and as I mentioned before, either compiling carbon explorer or using explorer to compile carbon code is a terrible operation as long as it requires that you have to use bazel, for China only, as China has no access to the various packages and deps of bazel, and unless there's an official public proxy or mirror, the nuisance caused by bazel is a pain in the ass. Sorry its frustrating. =/ We get a lot of benefit from Bazel and being able to scale out our dependencies though. There does seem to be instructions for separating when Bazel accesses the internet: https://bazel.build/run/build#running-bazel-airgapped I've not tried the repository cache approach, but if you or anyone else tries it out and has useful instructions for how to set it up and what to expect, I think that would be a great contribution to our docs to help folks out where internet access isn't easy. Beyond that, we are now publishing nightly builds here: https://github.com/carbon-language/carbon-lang/releases These should work on WSL, and don't require Bazel or anything else -- you can just extract and try things out. It only has the toolchain, not the explorer, as that's where most of our focus is these days. In general, I would expect these nightly builds to get better and better and be a much easier way to try something out quickly than building everything from source. The latter is really for folks who want to contribute to Carbon. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ddkwork]

https://github.com/carbon-language/carbon-lang/releases/tag/v0.0.0-0.nightly.2024.07.01

Will it run on Windows?

[chandlerc]

v0.0.0-0.nightly.2024.07.01 (release)

Will it run on Windows?

It should run on WSL. We don't have native Windows builds yet (that's the subject of this bug).

[ddkwork]

My starting point was also to build explorer on win11, halfway through the conversation because bazel couldn't proceed

…

---Original--- From: "Chandler ***@***.***> Date: Mon, Jul 1, 2024 14:39 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [carbon-language/carbon-lang] Building Carbon on Windows withoutWSL (#298) v0.0.0-0.nightly.2024.07.01 (release) Will it run on Windows? It should run on WSL. We don't have native Windows builds yet (that's the subject of this bug). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ddkwork]

If both bazel and cmake are supported, I'm sure explorer will support Windows before too long, and even if I fail, there are more people who can try it. cmake has almost no hellish limitations out of the box. bazel I have a feeling that unless you're in the US, it will keep loading dependencies until monkey business.

…

---Original--- From: "Chandler ***@***.***> Date: Mon, Jul 1, 2024 14:39 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [carbon-language/carbon-lang] Building Carbon on Windows withoutWSL (#298) v0.0.0-0.nightly.2024.07.01 (release) Will it run on Windows? It should run on WSL. We don't have native Windows builds yet (that's the subject of this bug). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[KateGregory]

Beyond that, we are now publishing nightly builds here: https://github.com/carbon-language/carbon-lang/releases

These should work on WSL, and don't require Bazel or anything else -- you can just extract and try things out. It only has the toolchain, not the explorer, as that's where most of our focus is these days. In general, I would expect these nightly builds to get better and better and be a much easier way to try something out quickly than building everything from source. The latter is really for folks who want to contribute to Carbon.

I can confirm that the nightly builds work on WSL with almost no other dependencies. I made a fresh Ubuntu and other than clang-16 needed nothing else to use the nightly builds. No bazel, nothing else.

[ddkwork]

No, the syntax of carbon is not very new to me, as I am very familiar with the go language. My intention is to make carbon work under Windows and not Linux!

…

---Original--- From: "Kate ***@***.***> Date: Mon, Jul 1, 2024 19:23 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [carbon-language/carbon-lang] Building Carbon on Windows withoutWSL (#298) Beyond that, we are now publishing nightly builds here: https://github.com/carbon-language/carbon-lang/releases These should work on WSL, and don't require Bazel or anything else -- you can just extract and try things out. It only has the toolchain, not the explorer, as that's where most of our focus is these days. In general, I would expect these nightly builds to get better and better and be a much easier way to try something out quickly than building everything from source. The latter is really for folks who want to contribute to Carbon. I can confirm that the nightly builds work on WSL with almost no other dependencies. I made a fresh Ubuntu and other than clang-16 needed nothing else to use the nightly builds. No bazel, nothing else. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[theoparis]

After removing -fPIC from clang_cc_toolchain_config.bzl (which is unsupported by clang on Windows), bazel got stuck on building flex due to libgen.h 😕

INFO: Invocation ID: a17454aa-d9e6-497a-b1e7-7ef704067ee0
ERROR: C:/users/theo/_bazel_theo/5q55gppw/external/rules_flex~~default_toolchain_ext~flex_v2.6.4/BUILD.bazel:20:11: Compiling src/main.c [for tool] failed: (Exit 1): clang failed: error executing CppCompile command (from target @@rules_flex~~default_toolchain_ext~flex_v2.6.4//:flex_lib) C:\Program Files\LLVM\bin\clang -no-canonical-prefixes -fcolor-diagnostics -Werror -Wall -Wextra -Wthread-safety -Wself-assign -Wimplicit-fallthrough -Wctad-maybe-unsupported -Wextra-semi ... (remaining 50 arguments skipped)
In file included from external/rules_flex~~default_toolchain_ext~flex_v2.6.4/src/main.c:35:
external/rules_flex~~default_toolchain_ext~flex_v2.6.4/src\flexdef.h:47:10: fatal error: 'libgen.h' file not found    
   47 | #include <libgen.h> /* for XPG version of basename(3) */
      |          ^~~~~~~~~~
1 error generated.
Target //explorer:explorer failed to build

If I disable building //explorer I get

clang: error: cannot compress debug sections (zlib not enabled) [-Werror,-Wdebug-compression-unavailable]

Removing -Werror from the clang_cc_toolchain_config.bzl file gets me further, but then I get

external/_main~llvm_project~llvm-project/llvm/lib/Support/BLAKE3/blake3_sse41_x86-64_unix.S:26:1: error: unknown directive
.hidden llvm_blake3_hash_many_sse41