windows: fix Envoy build on Windows #42687

anuraaga · 2025-12-18T07:53:59Z

Commit Message: Fix source to allow building on Windows
Additional Description:

I am interested in using Envoy on Windows with dynamic modules - I have already published pyvoy 0.2.0 using a patchset against 1.36.4 which is working great. This PR now updates the latest main to allow building on Windows, which required quite some more digging to accomodate changes to hermetic toolchains since then. FWIU, while Windows CI won't be restored, patches like this are still accepted.

For reference, the magic incantation to invoke Bazel

https://github.com/curioswitch/py-envoy-server/pull/17/files#diff-2855bcd1d44f7c4a97fdb2d631b71cf271ac70f3918e8f6242e54cf038952e64R59

If this is merged, I plan on having that build run nightly to try to catch Windows issues post-merge. Of course, if Envoy team could accept a small CI for Windows, just building the binary but no tests, that would be nice :) But I don't expect it.

There are two changes to non-Windows codepaths

For reverse tunnel downstream socket, a unix pipe is replaced with a pair of unix domain sockets (or TCP on windows). This allows using the Envoy OS helpers for this pattern. AFAIK, the only real difference with domain sockets would be they can be used bidirectionally, but if not, then at the kernel level they otherwise behave the same. Arguably using the helpers may be helping readability a little.

Otherwise, it is fixing some obvious syntax errors, including a dlopen wrapper around dynamic modules loading for Windows, replacing a convenience wrapper only available on newer windows with the older form, and other misc build tweaks.

/cc @mathetake @wbpcode

Risk Level:
Testing: CI
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

repokitteh-read-only · 2025-12-18T07:54:10Z

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @RyanTheOptimist

🐱

Caused by: #42687 was opened by anuraaga.

see: more, trace.

anuraaga · 2025-12-18T07:56:37Z

source/common/api/win32/os_sys_calls_impl.cc

 SysCallIntResult OsSysCallsImpl::setsockopt(os_fd_t sockfd, int level, int optname,
                                            const void* optval, socklen_t optlen) {
  if (optname == IP_RECVTOS || optname == IPV6_RECVTCLASS) {
-    const int rc = ::WSASetRecvIPEcn(sockfd, *(int*)optval == 1);


Only available on newer Windows

anuraaga · 2025-12-18T07:56:50Z

bazel/foreign_cc/luajit.patch

+new file mode 100755
+index 00000000..8fb0fbe8
+--- /dev/null
+++ b/luajit_build_win.sh


Shell version of old build.py that was deleted in refactoring

this should be in a separate patch - ie luajit_win.patch

the reason being is that anyon updating can just disable that patch easily/explicitly if it doesnt apply cleanly

we are not super consistent about this - but that is how we have been handling other arches recently

$ ls bazel/*ppc* bazel/highway-ppc64le.patch bazel/rules_java_ppc64le.patch bazel/v8_ppc64le.patch

anuraaga · 2025-12-18T07:57:03Z

bazel/foreign_cc/cel-cpp.patch

+-    args.use_param_file(param_file_arg = "%s", use_always = True)
+-    args.add_all(transitive_descriptor_sets)
+
+    # Generate script to concatenate files listed in a parameter file into an output file.


Relatively large change

can you upstream this its hard enough maintaining lots of patches, and even harder if its for untested OS

any windows specific patches should be in a separate clearly named patch - so maintainers can quickly disable it if it doesnt apply, and it doesnt affect any other builds

anuraaga · 2025-12-18T07:57:38Z

bazel/repo.bzl

+            tag = config_data["build-image"]["tag"],
+        ))
+    else:
+        # yq via bazel doesn't work on Windows, but we don't need the file either


It downloads something but doesn't symlink or copy it in a way that it can be run, probably a bazel rule bug in @yq but it doesn't matter here

source/extensions/bootstrap/reverse_tunnel/upstream_socket_interface/reverse_tunnel_acceptor.h

anuraaga · 2025-12-18T07:58:22Z

source/server/BUILD

        "//envoy/filesystem:filesystem_interface",
        "//source/common/common:logger_lib",
        "//source/common/filesystem:filesystem_lib",
+        "//source/common/singleton:threadsafe_singleton",


Something about clang-cl seems to detect more of these missing dependencies (correctly)

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

phlax

Windows CI won't be restored,

that is correct, and the related point is that developers have no obligation to make things work or keep things working

patches like this are still accepted.

we can accept patches to make it work if they are low maintenance and non-intrusive - but patches for upstream really must be upstreamed

@anuraaga im wondering what the motivation for this is - ie are you imagining envoy being deployed on windows somewhere?

if that is the case, and putting aside my own thoughts on whether that is a good idea, my strong suggestion would be to iniitiate a downstream project that kept up to date and did any ci/testing that is required to maintain this

bazel/foreign_cc/BUILD

phlax · 2025-12-18T10:47:53Z

bazel/foreign_cc/cel-cpp.patch

+-    args.use_param_file(param_file_arg = "%s", use_always = True)
+-    args.add_all(transitive_descriptor_sets)
+
+    # Generate script to concatenate files listed in a parameter file into an output file.


can you upstream this its hard enough maintaining lots of patches, and even harder if its for untested OS

any windows specific patches should be in a separate clearly named patch - so maintainers can quickly disable it if it doesnt apply, and it doesnt affect any other builds

phlax · 2025-12-18T10:50:08Z

bazel/foreign_cc/luajit.patch

+
+ ls
+ cd src
+./msvcbuild.bat static


in this cases its obviously harder to upstream the patch - but im wondering if this .bat stuff is really needed and if it is whether it can be incorporated to existing patch/script - eg by setting an env var and calling it here if set

I considered adding to the existing script but since it's not using make, most of the logic is actually replicating the install command. It seemed clearer to keep them separate

I was able to remove the .bat patch, instead making sure to copy vc140.pdb to the output prefix, which is required when using /Zi as msvcbuild.bat forces to use.

I still kept the separate build_win.sh since it seems worth keeping it independent from the unix one

phlax · 2025-12-18T10:52:02Z

bazel/com_google_protoconverter.patch

+ create_compiler_config_setting(
+     name = "config_msvc",
+-    value = "msvc-cl",
+    values = ["msvc-cl", "clang-cl"],


please upstream all of this

phlax · 2025-12-18T10:56:30Z

tools/BUILD

    "check_repositories.sh",
 ])

+py_binary(


move this into tools/windows if its not relevant to anyone else

anuraaga · 2025-12-18T12:03:45Z

my strong suggestion would be to iniitiate a downstream project that kept up to date

Not sure if I follow exactly but yes, this is the linked pyvoy. And yeah, I don't expect Envoy to bring back any CI and will need to do testing.

I am wondering what part of this change is acceptable to you - if it's only the cc/h files that would still be helpful and I will just keep the build code forked. As we know, most of these dependencies aren't well maintained so while I can try to upstream changes, generally it won't work.

grpc-ecosystem/proto-converter#6

phlax · 2025-12-18T12:14:24Z

Not sure if I follow exactly

i meant something like an envoy-on-windows project that ran a build and some tests - we have a similar situation with unsupported arches (eg ppcle) and builds (eg openssl) already

ideally we make as few changes as possible wrt maintaining win-specific changes - i think the changes to our cc/h are unaviodable, and similar with some of the bazel selects etc - but for unsupported setups its even more important to upstream upstream changes as it significantly complicates maintaining patches

@TAOXUY @dchakarwarti would you be able to review a PR to upstream these changes?

anuraaga · 2025-12-18T12:29:00Z

i meant something like an envoy-on-windows project that ran a build and some tests

Ah I see. That would be the workflow I plan on running in py-envoy-server which just packages Envoy for use in Python.

https://github.com/curioswitch/py-envoy-server/blob/main/.github/workflows/envoy-windows-upstream.yaml

It builds envoy and runs some tests. Not a full suite but it checks basic functionality. I don't have a big reason to separate out yet another project specifically for envoy-on-windows but in terms of the envoy repo I think it's effectively the same.

but for unsupported setups its even more important to upstream upstream changes as it significantly complicates maintaining patches

Yeah I agree that it can get hard to recreate them. TBH I was already prepping a PR for protoconverter before finding that stale PR. I'm always for upstreaming where I can.

Is there any model where upstream patches with windows code can be made knowing that updates to the patch may break? I'm definitely not expecting the code to be stable for Windows and would just need to be able to react, not proact. But if even that's too much can keep those patches out of this PR.

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga

I was able to simplify the build patches, sent grpc-ecosystem/proto-converter#7 in case it may be merged.

cel-cpp seems to have coincidentally started looking into Windows issues recently

google/cel-cpp#1811
google/cel-cpp@f1a2e8e

The now one-line patch here seems to work for now and in the future it should be removable.

bazel/foreign_cc/BUILD

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga

@phlax I was able to simplify the upstream patches a lot with pointers to upstreaming. Hopefully this looks better now

anuraaga · 2025-12-19T06:01:13Z

bazel/foreign_cc/luajit.patch

+
+ ls
+ cd src
+./msvcbuild.bat static


I was able to remove the .bat patch, instead making sure to copy vc140.pdb to the output prefix, which is required when using /Zi as msvcbuild.bat forces to use.

I still kept the separate build_win.sh since it seems worth keeping it independent from the unix one

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

…indows-build

ravenblackx · 2025-12-26T19:51:09Z

Ping for @wbpcode - but it's vacation season so mostly this ping is to shush the tool that nags on-call about stalled PRs, we don't expect prompt reviews across vacations.

…indows-build

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

kyessenov · 2026-01-06T18:24:32Z

Gentle ping to reviewers. @wbpcode @phlax .

phlax

@anuraaga i would feel a lot more comfortable supporting this if there were a downstream project - ie more than one user

either way - my main goals here are

prevent lots of cruft that is not used (which we dont know if theres no ci)
avoid adding complexity
ensure it doesnt add any maintenance burden to devs

the last point is crucial - its why we dropped support previously (that and terrible ci)

bazel/foreign_cc/BUILD

phlax · 2026-01-06T18:30:09Z

bazel/foreign_cc/cel-cpp.patch

+         progress_message = "Joining descriptors.",
+         command = ("< \"$1\" xargs cat >{output}".format(output = output.path)),
+         arguments = [args],
+        use_default_shell_env = True,


can this be upstreamed?

A much larger patch upstream to remove shell usage was already merged, along with some other Windows fixes, so once the next version of cel-cpp is released and updated to, it should work fine without patching. So I have removed this patch from the PR and will maintain it downstream until then so it's easier to delete

phlax · 2026-01-06T18:33:11Z

bazel/foreign_cc/luajit.patch

+new file mode 100755
+index 00000000..8fb0fbe8
+--- /dev/null
+++ b/luajit_build_win.sh


this should be in a separate patch - ie luajit_win.patch

the reason being is that anyon updating can just disable that patch easily/explicitly if it doesnt apply cleanly

we are not super consistent about this - but that is how we have been handling other arches recently

$ ls bazel/*ppc* bazel/highway-ppc64le.patch bazel/rules_java_ppc64le.patch bazel/v8_ppc64le.patch

phlax · 2026-01-06T18:34:52Z

bazel/com_google_protoconverter.patch

@@ -1,3 +1,32 @@
+diff --git a/build_defs/BUILD.bazel b/build_defs/BUILD.bazel
+index 732514d..a6be18b 100644


same with this patch - please put it to a win name

phlax · 2026-01-06T18:41:19Z

bazel/repo.bzl

+        ))
+    else:
+        # yq via bazel doesn't work on Windows, but we don't need the file either
+        repository_ctx.file("containers.bzl", CONTAINERS.format(


pretty sure we dont need to repeat this

wondering if this file is needed at all in the windows case, assuming it is - then probably it can just be empty

if for some reason that doesnt work - i think its marginally cleaner to do something like

repo = "" repo_gcr = "" ... if not windows condition: set vars from parsed config repository_ctx.file(...)

IIUC, we can't avoid it since the values are directly loaded during repo and toolchain resolution

https://github.com/envoyproxy/envoy/blob/main/bazel/platforms/rbe/BUILD#L2

I think this is the reason we can't use genrule either. I went with the suggested style though since it does seem better

bazel/repositories.bzl

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga

Thanks @phlax - I have applied the suggestions and hope it gets closer to a balance that doesn't get in the way of other developers. AFAIK, I am not introducing a new feature or paradigm but just fixing an existing one, best-effort building on Windows. Basically I am just trying to offer free help keeping the binary building on Windows, which I'll be using a nightly CI to do going forward too.

I think it's worth keeping in perspective that the Windows logic here also isn't that large among all the other tooling - unmaintained dependencies like proto-converter seem to be larger issues to clamp down on ;)

Anyways let me know what works for you and I will target it, I can maintain as much of this patch downstream as needed, including all of it if it's completely declined.

anuraaga · 2026-01-07T01:38:10Z

bazel/foreign_cc/cel-cpp.patch

+         progress_message = "Joining descriptors.",
+         command = ("< \"$1\" xargs cat >{output}".format(output = output.path)),
+         arguments = [args],
+        use_default_shell_env = True,


A much larger patch upstream to remove shell usage was already merged, along with some other Windows fixes, so once the next version of cel-cpp is released and updated to, it should work fine without patching. So I have removed this patch from the PR and will maintain it downstream until then so it's easier to delete

bazel/foreign_cc/BUILD

anuraaga · 2026-01-07T01:56:34Z

bazel/repo.bzl

+        ))
+    else:
+        # yq via bazel doesn't work on Windows, but we don't need the file either
+        repository_ctx.file("containers.bzl", CONTAINERS.format(


IIUC, we can't avoid it since the values are directly loaded during repo and toolchain resolution

https://github.com/envoyproxy/envoy/blob/main/bazel/platforms/rbe/BUILD#L2

I think this is the reason we can't use genrule either. I went with the suggested style though since it does seem better

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

phlax

deps lgtm, thanks @anuraaga

@wbpcode could you give it a code review

anuraaga requested review from agrawroh, botengyao, mathetake, mattklein123 and yanavlasov as code owners December 18, 2025 07:54

repokitteh-read-only bot added the deps Approval required for changes to Envoy's external dependencies label Dec 18, 2025

repokitteh-read-only bot assigned RyanTheOptimist Dec 18, 2025

anuraaga commented Dec 18, 2025

View reviewed changes

Fix Envoy build on Windows

080845b

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga force-pushed the fix-windows-build branch 2 times, most recently from 60681f4 to 1d6c084 Compare December 18, 2025 08:13

Remove redundant move

6fcbc41

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga force-pushed the fix-windows-build branch from 1d6c084 to 6fcbc41 Compare December 18, 2025 08:19

Lints

8b02976

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga force-pushed the fix-windows-build branch from b317301 to 8b02976 Compare December 18, 2025 09:02

phlax self-assigned this Dec 18, 2025

phlax reviewed Dec 18, 2025

View reviewed changes

anuraaga added 3 commits December 19, 2025 13:10

Simplify cel-cpp patch

cd0e20d

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Simplify protoconverter patch

d42ba51

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Move script to windows folder

e0bfb72

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga commented Dec 19, 2025

View reviewed changes

bazel/foreign_cc/BUILD Show resolved Hide resolved

anuraaga added 4 commits December 19, 2025 14:13

Simplify luajit patch

4d1fee3

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Formatting

2ce46e6

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Preserve trailing whitespace

e05b8fd

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

luajit incremental link

f1dc4f8

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga commented Dec 19, 2025

View reviewed changes

anuraaga added 2 commits December 19, 2025 15:14

Remove leftover rule

db16aa1

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Merge branch 'main' of https://github.com/envoyproxy/envoy into fix-w…

7e8341b

…indows-build

wbpcode self-assigned this Dec 22, 2025

Merge branch 'main' of https://github.com/envoyproxy/envoy into fix-w…

ec35983

…indows-build

anuraaga requested a review from wbpcode as a code owner January 6, 2026 05:21

anuraaga force-pushed the fix-windows-build branch from 00bdf7c to b22a8e4 Compare January 6, 2026 07:19

Add network filter to dep allowlist.

c6f5fc6

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga force-pushed the fix-windows-build branch from b22a8e4 to c6f5fc6 Compare January 6, 2026 07:37

phlax reviewed Jan 6, 2026

View reviewed changes

anuraaga added 2 commits January 7, 2026 10:41

Separate windows patches

e04dab6

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Cleanup containers.bzl

3766659

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga commented Jan 7, 2026

View reviewed changes

anuraaga added 2 commits January 7, 2026 11:57

Formatting

95bb385

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

Restore luajit compile flags

a60d4d5

Signed-off-by: Anuraag Agrawal <anuraaga@gmail.com>

anuraaga force-pushed the fix-windows-build branch from 9a3f1ad to a60d4d5 Compare January 7, 2026 05:42

phlax approved these changes Jan 7, 2026

View reviewed changes

repokitteh-read-only bot removed the deps Approval required for changes to Envoy's external dependencies label Jan 7, 2026

		@@ -1,3 +1,32 @@
		diff --git a/build_defs/BUILD.bazel b/build_defs/BUILD.bazel
		index 732514d..a6be18b 100644

windows: fix Envoy build on Windows #42687

Are you sure you want to change the base?

windows: fix Envoy build on Windows #42687

Uh oh!

Conversation

anuraaga commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

repokitteh-read-only bot commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phlax left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anuraaga commented Dec 18, 2025

Uh oh!

phlax commented Dec 18, 2025

Uh oh!

anuraaga commented Dec 18, 2025

Uh oh!

anuraaga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

anuraaga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ravenblackx commented Dec 26, 2025

Uh oh!

kyessenov commented Jan 6, 2026

Uh oh!

phlax left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

anuraaga left a comment

Choose a reason for hiding this comment

Uh oh!

anuraaga commented Dec 18, 2025 •

edited

Loading