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

I do have no confidence to evaluate this change.

Thanks @wbpcode - I did a deeper dive. I found the branch added in https://github.com/envoyproxy/envoy/pull/32644/changes#diff-438743665cbf68415faee3a0caaaf846ad02aba05628edb5628123853827c264 when adding plumbing of ECN to Envoy, though AFAIK, it is still not read anywhere.

After investigation, I found that IP_RECVTOS and IPV6_RECVTCLASS set a full TOS byte, including ECN bits. This seems to work on windows too and is well documented

https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options
https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ipv6-socket-options

"All DSCP and ECN bits of the TOS field will be returned"

Windows does document "For type-safety, you should use the WSAGetRecvIPEcn and WSASetRecvIPEcn functions" but I think this type-safety can't apply if we have to use setsockopt anyways, it would be to avoid that function.

As just using IP_RECVTOS / IPV6_RECVTCLASS as-is on Windows should produce the same behavior as Linux, I just removed the branch. How does that sound?

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

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

wbpcode

Thanks so much for this contribution. we do ignore the windows for a while and seems there are some basic error need to fix.

here are some suggestion:

except the extension you want to use, like dynamic modules, for other filters that cannot run under windows for now, just compile it out rather then add patch or fix it.
try not introduce new dependency if possible.

wbpcode · 2026-01-10T13:33:20Z

bazel/foreign_cc/luajit_win.patch

+ @rem Add more debug flags here, e.g. DEBUGCFLAGS=/DLUA_USE_ASSERT
+ @set DEBUGCFLAGS=
+ @set LJCOMPILE=cl /nologo /c /O2 /W3 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_STDIO_INLINE=__declspec(dllexport)__inline
+-@set LJDYNBUILD=/DLUA_BUILD_AS_DLL /MD
+-@set LJDYNBUILD_DEBUG=/DLUA_BUILD_AS_DLL /MDd 
+-@set LJCOMPILETARGET=/Zi
+@rem Use MT to match flags set by bazel for static build
+@set LJDYNBUILD=/DLUA_BUILD_AS_DLL /MT
+@set LJDYNBUILD_DEBUG=/DLUA_BUILD_AS_DLL /MTd 
+@rem Avoid incremental link which doesn't work with bazel's deletion of intermediate files
+@set LJCOMPILETARGET=/Z7
+ @set LJLINKTYPE=/DEBUG /RELEASE
+ @set LJLINKTYPE_DEBUG=/DEBUG
+ @set LJLINKTARGET=/OPT:REF /OPT:ICF /INCREMENTAL:NO


If we need additional patch for these extensions (lua, protocolconverter related) works, could we just compile it out rather then add additional patches?

wbpcode · 2026-01-10T13:35:26Z

bazel/repository_locations.bzl

+    com_github_dlfcn_win32 = dict(
+        project_name = "dlfcn-win32",
+        project_desc = "An implementation of dlfcn for Windows.",
+        project_url = "https://github.com/dlfcn-win32/dlfcn-win32",
+        version = "1.4.2",
+        sha256 = "f61a874bc9163ab488accb364fd681d109870c86e8071f4710cbcdcbaf9f2565",
+        strip_prefix = "dlfcn-win32-{version}",
+        urls = ["https://github.com/dlfcn-win32/dlfcn-win32/archive/refs/tags/v{version}.tar.gz"],
+        use_category = ["dataplane_ext"],
+        extensions = [
+            "envoy.filters.http.dynamic_modules",
+            "envoy.filters.listener.dynamic_modules",
+            "envoy.filters.network.dynamic_modules",
+        ],
+        release_date = "2025-03-04",
+        cpe = "N/A",
+        license = "MIT",
+        license_url = "https://github.com/dlfcn-win32/dlfcn-win32/blob/v{version}/COPYING",
+    ),


Could we use macro to use the method from windows to load the dynamic library rather then use a new dependency? Or will it be very complex?

I initially considered skipping the dependency after verifying everything works. But the management of function pointers that this library takes care of seemed complicated enough to consider taking advantage of the dependency - the loaded DLLs are in a sense "highly stateful" so difficult to macro

wbpcode · 2026-01-10T13:41:05Z

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


I do have no confidence to evaluate this change.

wbpcode · 2026-01-10T13:44:22Z

...ensions/bootstrap/reverse_tunnel/downstream_socket_interface/reverse_connection_io_handle.cc

-  if (trigger_pipe_write_fd_ >= 0) {
-    ::close(trigger_pipe_write_fd_);
-    trigger_pipe_write_fd_ = -1;
+  auto& os_sys_calls = Api::OsSysCallsSingleton::get();
+  if (trigger_pipe_write_fd_ != INVALID_SOCKET) {
+    os_sys_calls.close(trigger_pipe_write_fd_);
+    trigger_pipe_write_fd_ = INVALID_SOCKET;
  }
-  if (trigger_pipe_read_fd_ >= 0) {
-    ::close(trigger_pipe_read_fd_);
-    trigger_pipe_read_fd_ = -1;
+  if (trigger_pipe_read_fd_ != INVALID_SOCKET) {
+    os_sys_calls.close(trigger_pipe_read_fd_);
+    trigger_pipe_read_fd_ = INVALID_SOCKET;


Great change. But may it's easier to compile this extension out. This is a very new features and no one will require it on windows for now.

wbpcode · 2026-01-10T13:51:40Z

/wait

anuraaga

Thanks @wbpcode - at first I thought about filtering extensions, but thought it could be nice to just "refresh the build" for Windows to get it caught up so dug deep to figure things out. Now that they're in, reverting them would mean they're lost along with the time digging. I can do it though, but with the patches now well separated, does it seem ok to give it a try? Especially lua I think can still potentially have interesting use cases.

reverse_tunnel I have the least feelings for, and as you say since it's new and actively being modified, could make sense to leave out. One of the reasons I kept it is it seemed the code ended up cleaner after the changes than before. But let me know any thoughts on it.

anuraaga · 2026-01-10T14:01:08Z

bazel/repository_locations.bzl

+    com_github_dlfcn_win32 = dict(
+        project_name = "dlfcn-win32",
+        project_desc = "An implementation of dlfcn for Windows.",
+        project_url = "https://github.com/dlfcn-win32/dlfcn-win32",
+        version = "1.4.2",
+        sha256 = "f61a874bc9163ab488accb364fd681d109870c86e8071f4710cbcdcbaf9f2565",
+        strip_prefix = "dlfcn-win32-{version}",
+        urls = ["https://github.com/dlfcn-win32/dlfcn-win32/archive/refs/tags/v{version}.tar.gz"],
+        use_category = ["dataplane_ext"],
+        extensions = [
+            "envoy.filters.http.dynamic_modules",
+            "envoy.filters.listener.dynamic_modules",
+            "envoy.filters.network.dynamic_modules",
+        ],
+        release_date = "2025-03-04",
+        cpe = "N/A",
+        license = "MIT",
+        license_url = "https://github.com/dlfcn-win32/dlfcn-win32/blob/v{version}/COPYING",
+    ),


I initially considered skipping the dependency after verifying everything works. But the management of function pointers that this library takes care of seemed complicated enough to consider taking advantage of the dependency - the loaded DLLs are in a sense "highly stateful" so difficult to macro

wbpcode · 2026-01-11T12:26:04Z

Thanks @wbpcode - at first I thought about filtering extensions, but thought it could be nice to just "refresh the build" for Windows to get it caught up so dug deep to figure things out. Now that they're in, reverting them would mean they're lost along with the time digging. I can do it though, but with the patches now well separated, does it seem ok to give it a try? Especially lua I think can still potentially have interesting use cases.

reverse_tunnel I have the least feelings for, and as you say since it's new and actively being modified, could make sense to leave out. One of the reasons I kept it is it seemed the code ended up cleaner after the changes than before. But let me know any thoughts on it.

I see. Then maybe we cooke only keep lua there? And for extensions, we can compile it out (we have ignored lots of extensions anyway), and you could keep a backup and then, you may create a separated PR to make them works for windows if you do want them?

…indows-build

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

anuraaga

Ok @wbpcode I have removed reverse_tunnel and kicked off a build

https://github.com/curioswitch/py-envoy-server/actions/runs/20772038791/job/60062804782

I couldn't remove protoconverter since it is used in common

https://github.com/envoyproxy/envoy/blob/main/source/common/protobuf/BUILD#L56

The patch is small and repo mostly frozen, so hopefully it's ok (ideally you consider following up on the future of that dependency itself outside this PR).

anuraaga · 2026-01-12T03:29:08Z

source/extensions/clusters/reverse_connection/reverse_connection.h

 #include <sys/socket.h>

+#else
+#include <winsock2.h>


While this probably is similar to reverse_tunnel, the patch is so small I couldn't see a need to remove it

Nevermind I found it depended on the others that were excluded

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

anuraaga · 2026-01-12T14:40:42Z

Thanks everyone - I'm going to go ahead and close this PR. The first comment was already not too receptive to it, and the latest, continues prioritizing maintainers over the Windows build. I tried to still accommdate it, but it has actually increased the work trying to get to something that builds. I understand that Envoy doesn't actually care to be buildable on Windows (unlike Apache, nginx, etc) and that's fine, I'll deal with it downstream.

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

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 previously 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

wbpcode reviewed Jan 10, 2026

View reviewed changes

repokitteh-read-only bot added the waiting label Jan 10, 2026

anuraaga commented Jan 10, 2026

View reviewed changes

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

0774afa

…indows-build

anuraaga dismissed phlax’s stale review via f1d9e34 January 12, 2026 03:21

repokitteh-read-only bot added deps Approval required for changes to Envoy's external dependencies and removed waiting labels Jan 12, 2026

anuraaga added 2 commits January 12, 2026 12:24

Filter reverse_tunnel from windows build

d94d500

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

Revert reverse_tunnel

e8b89e6

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

anuraaga force-pushed the fix-windows-build branch from f1d9e34 to e8b89e6 Compare January 12, 2026 03:24

anuraaga commented Jan 12, 2026

View reviewed changes

anuraaga added 5 commits January 12, 2026 13:21

More extensions

f1c99d2

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

Remove mapping RECVTOS to ECN on Windows

b1e4e71

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

More extensions

646541d

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

more filter

a778915

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

Disable clusters.reverse_connection

fe412a0

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

anuraaga closed this Jan 12, 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

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!

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!

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

anuraaga commented Dec 18, 2025 •

edited

Loading